Quartz 4

Henry Preferences — Founder Operating Standards Hub

6 min read

Henry Preferences — Founder Operating Standards Hub

This hub mirrors the durable operating standards in HENRY-PREFERENCES.md authored by Henry Hill. Read this hub first whenever reviewing plan structure, formatting content for Henry, making decisions, or sending external communications. These are mandatory rules, not suggestions — they apply automatically unless Henry explicitly overrides in the current session. Curator: henry. Review cadence: monthly (any session where Henry modifies the source).

Quick reference

FieldValue
Source docHENRY-PREFERENCES
Source doc last updated2026-03-17
Canonical path/home/opsadmin/.openclaw/workspace/HENRY-PREFERENCES.md
Curatorhenry
Review cadencemonthly
Staleness riskHIGH — see Staleness audit section
Applies to agents_summary, _summary, _summary, _summary, all 42 active agents
Governance gates enforced[G-GOVERNANCE-LOG-FRESHNESS]

Staleness audit

Source document is 48 days stale as of 2026-05-04.

  • Source internal “Last updated” line: 2026-03-17
  • Today’s date: 2026-05-04
  • Days stale: 48 days
  • G-GOVERNANCE-LOG-FRESHNESS threshold: 14 days
  • Status: VIOLATION — 3.4x over threshold

Action required: Henry should review HENRY-PREFERENCES.md for any changes since 2026-03-17 and update the “Last updated” line. Sections most likely to have drifted given recent activity:

  • §4 “Every Question Must Carry a Recommendation” (added 2026-04-15 per inline note — source may already be updated but file header stale)
  • §4 “Options Listed Vertically, Never Run-On” (added 2026-05-01 per inline note)
  • §6 Founder Shorthand table (may need new rows for Wave series commands)

The source file frontmatter shows last-reviewed: 2026-05-03 (likely auto-updated by vault sync) but the internal content header says Last updated: 2026-03-17. These are inconsistent — the internal date is authoritative for content freshness.

Standards index

§1 Review and Correction Standards

  • Content-based operations, never line-based — parse semantic blocks, never hardcoded line numbers
  • Authority hierarchy — SESSION-AUDIT.md NEXT ACTIONS is the authoritative continuity ledger; agent registries are authoritative for ownership
  • Explicit dependencies — every design decision lists what it depends on; post-execution cross-file audit is required
  • Verification tests for every behavior — every new behavior needs a corresponding verification test
  • Block-based parsing — define blocks semantically (e.g., ### Session Summary through next ### or EOF)
  • Freshness bounds — apply recency constraints when picking from multiple candidates
  • Distinguish doc changes from code changes — separate risk profiles, separate rollback strategies

§2 Plan Architecture Standards

  • System-first audits, not feature roadmaps — required sections: Self-Check Findings, SoT Matrix, Data Flow Audit, Keep/Rework/Replace/Remove table
  • Scope reframing before Phase 0 — ask “what problem are we actually solving?” before starting
  • Phase 0 is always temporary containment — later phases replace Phase 0 hacks
  • Anti-scope section required — every plan must include “What this plan should NOT build”
  • Plan file naming convention — [category]-[topic].md; NEVER auto-generated random names
  • Plan Q&A lifecycle — Q blocks with (pending) answers MUST be revisited before Phase 1
  • Hard execution gates — stop/go gates between layers; all criteria must pass before next layer

§3 Execution Standards

  • Search before building — grep codebase, check Supabase, check workspace/scripts/ before creating anything
  • Bridge file at Completion Packet — every session reaching Completion Packet stage
  • Post-Plan Assimilation mandatory — run POST-PLAN-ASSIMILATION.md checklist after major work
  • Completion Packet required — what changed, state, verify, tests, docs, follow-ups

§4 Communication Standards

  • No em dashes — never in drafts, emails, or written content
  • Email formatting — no tables, bold key areas, persuasive tone, no em dashes, copy-paste ready
  • Feedback via AskUserQuestion — always use tool, never plain text
  • Every question must carry a recommendation — Options (vertical, A/B/C) + Recommend + Why + Override cost
  • Options listed vertically — never run-on with | or / separators; one option per line
  • Comprehensive by default — full 8-section format unless Henry says “quick/minimal”
  • Copy-paste ready outputs — no placeholder brackets unless explicitly marked “[FILL IN]“

§5 Governance Standards

  • Friction report integration — every plan addresses “How this reduces tomorrow’s friction report”
  • Skill consolidation in every plan — name, purpose, contract, agents made redundant
  • One canonical handler per platform — HubSpot = hubspot-handler.js, OpenPhone = quo-handler-enhanced.js
  • Post-Plan Assimilation is mandatory — after any major plan, audit, architecture review

§6 Founder Shorthand Interpretation

Key shorthands (see source for full table):

  • “optimize” / “make this better” → audit for missing logic, drift, higher-leverage improvements
  • “what’s missing” / “blind spots” → run plan-review-audit workflow
  • “enterprise level” / “production ready” → system-first audit
  • “where are we at” → read SESSION-AUDIT + ACTIVE PLANS + recent plan files

§7 Severity and Priority Model

  • Severity: P0 Critical / P1 High / P2 Medium / P3 Low
  • Workflow state: proposed → approved → active → blocked → implemented → verified → superseded → archived

How it’s used

  • Before asking Henry any question — check §4 rules on recommendation format and vertical options list
  • Before writing any plan — check §2 naming convention, anti-scope requirement, and gate structure
  • Before sending any external communication — check §4 email formatting rules (no tables, no em dashes)
  • Before executing any work — check §3 search-before-building and bridge file requirements
  • During plan review — check §2 system-first audit mandate and scope reframing
  • Failure mode: skipping §4 vertical-options rule is the most common violation; second most common is missing bridge file at session end

Plans that govern this

Feedback rules

  • action-gate — operationalizes §3 execution standards
  • plan-governance — operationalizes §2 plan architecture standards
  • sources-first — operationalizes §1 review and correction standards
  • blockers-first — operationalizes blocker surfacing before execution

Team hubs

  • henry-founder — Henry’s context, authority, and communication preferences
  • workflow-patterns — recurring workflows that apply these preferences
  • runbooks-master — runbooks that implement these standards
  • kb-directory — KB docs that Claude must check before building (§3 Search Before Building)

System maps

Knowledge curation cluster

This hub is a member of the Knowledge curation cluster anchored at kb-directory.

HubRole in cluster
kb-directoryAnchor — 165 KB platform docs Claude must check first
henry-preferencesFounder operating standards — rules for HOW Claude works
workflow-patternsRecurring patterns — canonical procedures
runbooks-masterTactical runbooks — step-by-step procedures
templates-libraryTemplates — structured scaffolds for new files

Open issues / TODOs

  • Source document is 48 days stale — Henry should review and update HENRY-PREFERENCES.md
  • Confirm §4 additions (2026-04-15 recommendation rule, 2026-05-01 vertical options rule) are reflected in body text — they appear inline but file header says Last updated: 2026-03-17
  • After Henry refreshes source, update this hub’s “Source doc last updated” field and re-run staleness audit

Recent activity

  • 2026-05-04: hub created (W3-S1, Wave 3 resource hubs batch)

Graph View

Backlinks