create-claude-cabinet 0.6.0

package/templates/briefing/_briefing-template.md

@@ -0,0 +1,148 @@
+# Briefing File System — Guide
+
+The cabinet system uses **split briefing files** instead of a single
+monolithic `_briefing.md`. Each file focuses on one domain of project
+knowledge, and cabinet members declare which files they need in their
+frontmatter. This keeps briefing loading focused — a cabinet member that
+only needs identity and paths doesn't load API configuration or work
+tracking details.
+
+## Architecture
+
+A **hub file** (`_briefing.md`) indexes the focused briefing files that
+exist for this project. Cabinet members read the specific files they need
+rather than parsing one large document.
+
+```
+_briefing.md                  ← Hub/index (always exists)
+_briefing-identity.md         ← What the project is (always exists)
+_briefing-architecture.md     ← System structure, codebase layout
+_briefing-scopes.md           ← Where to look (paths)
+_briefing-cabinet.md          ← Active cabinet members, portfolio rules
+_briefing-work-tracking.md    ← Work item storage and interfaces
+_briefing-api.md              ← API config, entity types
+_briefing-{domain}.md         ← Domain extensions (see below)
+```
+
+## File Descriptions
+
+### `_briefing.md` — Hub/Index
+**Always created.** Lists which briefing files exist and a one-line
+summary of each. This is what cabinet members fall back to if they don't
+declare specific briefing needs.
+
+### `_briefing-identity.md` — Project Identity
+**Always created.** What the project is, core principles, user context.
+Every cabinet member needs this — it calibrates all findings. Template:
+`_briefing-identity-template.md`.
+
+### `_briefing-architecture.md` — Architecture
+System structure, codebase layout, technology stack. Needed by
+cabinet members that evaluate code structure or need to understand where
+things live. Template: `_briefing-architecture-template.md`.
+
+### `_briefing-scopes.md` — Paths
+Where to look for different kinds of code and configuration. Sections
+are referenced by name (e.g., "App Source", "Data Store"). Only fill in
+sections relevant to the cabinet members you adopt. Template:
+`_briefing-scopes-template.md`.
+
+### `_briefing-cabinet.md` — Cabinet
+Which cabinet members are active, portfolio rules, invocation patterns.
+Needed by meta cabinet members that evaluate the cabinet system itself.
+Template: `_briefing-cabinet-template.md`.
+
+### `_briefing-work-tracking.md` — Work Tracking
+How the project tracks planned work — storage, query interface,
+mutation interface. Referenced by /plan, /execute, /orient, /debrief.
+Template: `_briefing-work-tracking-template.md`.
+
+### `_briefing-api.md` — API Configuration
+Endpoints, auth, entity types. Only create this if the project has an
+API. Template: `_briefing-api-template.md`.
+
+## Cabinet Member-to-Briefing Mapping
+
+Which cabinet members need which briefing files (identity is always loaded):
+
+| Cabinet Member        | architecture | scopes | cabinet | work-tracking | api |
+|-----------------------|:---:|:---:|:---:|:---:|:---:|
+| accessibility         |     |  x  |     |     |     |
+| anti-confirmation     |     |     |     |     |     |
+| architecture          |  x  |  x  |     |     |     |
+| boundary-man          |  x  |  x  |     |     |     |
+| cor-health            |     |  x  |  x  |     |     |
+| data-integrity        |  x  |  x  |     |     |  x  |
+| debugger              |  x  |     |     |     |     |
+| record-keeper         |     |  x  |     |     |     |
+| historian             |  x  |     |     |     |     |
+| process-therapist     |     |  x  |  x  |     |     |
+| small-screen          |     |  x  |     |     |     |
+| organized-mind        |  x  |     |     |     |     |
+| speed-freak           |  x  |  x  |     |     |     |
+| workflow-cop          |     |  x  |     |     |     |
+| qa                    |  x  |  x  |     |     |     |
+| security              |  x  |  x  |     |     |  x  |
+| roster-check          |     |     |  x  |     |     |
+| system-advocate        |     |     |  x  |     |     |
+| technical-debt        |  x  |     |     |     |     |
+| usability             |     |  x  |     |     |     |
+
+## Domain Extension Files
+
+Specialized cabinet members may need domain-specific briefing that doesn't
+fit the standard files. These are created by `/seed` when a specialized
+cabinet member is adopted:
+
+- **`_briefing-methodology.md`** — For methodology-compliance or GTD
+  cabinet members. Contains methodology rules, review cadences, horizon
+  definitions.
+- **`_briefing-design-system.md`** — For framework-quality or
+  information-design cabinet members. Contains design tokens, component
+  conventions, layout patterns.
+- **Any `_briefing-{domain}.md`** — A cabinet member can declare any briefing
+  file it needs in its frontmatter. If the file doesn't exist, the
+  cabinet member falls back to the hub.
+
+## Files Are Optional
+
+Only create briefing files relevant to your project. A CLI tool with no
+UI doesn't need `_briefing-scopes.md` App Source. A project without an
+API skips `_briefing-api.md` entirely. The hub `_briefing.md` lists what
+exists so cabinet members know what's available.
+
+## How These Files Get Created
+
+- **/onboard** generates the initial set from interview answers. It
+  always creates the hub and identity file. Other files are created
+  only if the interview produced content for them.
+- **/seed** adds domain extension files when specialized cabinet members
+  are adopted.
+- **/cor-upgrade** can migrate a monolithic `_briefing.md` into the
+  split format.
+
+## Backward Compatibility
+
+The old monolithic `_briefing.md` format still works. If a cabinet member
+declares briefing files in its frontmatter but those files don't exist,
+or if no `briefing` field is present, the system falls back to reading
+`_briefing.md` directly. This means:
+
+- Existing projects with a monolithic `_briefing.md` continue to work
+  without changes.
+- Projects can migrate incrementally — split out one file at a time.
+- `/cor-upgrade` handles the full migration when the project is ready.
+
+## Finding Format
+
+When producing audit findings, use this structure:
+
+```yaml
+finding:
+  cabinet-member: member-name
+  severity: critical | significant | minor | informational
+  category: what domain this falls under
+  description: what was found
+  evidence: specific file:line or observation
+  recommendation: what to do about it
+```

package/templates/briefing/_briefing-work-tracking-template.md

@@ -0,0 +1,18 @@
+# Work Tracking — [Your Project Name]
+
+How this project tracks planned work. Skills that manage work items
+(/plan, /execute, /orient, /debrief) reference this file.
+
+## Work Item Storage
+*Where work items live.*
+*Example: SQLite `tasks` table, or `backlog.md`, or GitHub Issues*
+
+## Query Interface
+*How to search open items.*
+*Example: `sqlite3 project.db "SELECT * FROM tasks WHERE status != 'done'"`*
+*Example: `gh issue list --state open --json number,title`*
+
+## Mutation Interface
+*How to create, update, and close items.*
+*Example: `POST /api/tasks` with JSON body*
+*Example: `gh issue create --title "..." --body "..."`*

package/templates/cabinet/committees-template.yaml

@@ -0,0 +1,49 @@
+# Cabinet member committees — canonical mapping of committee slugs to cabinet member lists.
+#
+# Copy this file as committees.yaml and uncomment/customize the committees that
+# match your project. Technology choices imply expertise needs: if your
+# project has a UI, you need a UI committee. If it has an API, you need
+# a system health committee.
+#
+# Consumed by:
+#   - /audit skill (committee selection menu)
+#   - scripts (--committee flag, resolve-committees helpers)
+#
+# Cross-portfolio cabinet members are NOT in any committee. They activate via
+# standing-mandate in their SKILL.md frontmatter:
+#   anti-confirmation, qa, debugger, organized-mind
+
+committees:
+  # -- If your project has a user interface --
+  # ux:
+  #   name: "UX & Design"
+  #   members:
+  #     - accessibility
+  #     - small-screen
+  #     # Add framework-specific cabinet members (e.g., mantine-quality, tailwind-quality)
+
+  # -- If your project has code (most projects) --
+  # code:
+  #   name: "Code Quality"
+  #   members:
+  #     - technical-debt
+  #     - boundary-man
+  #     # Add: architecture (if multi-layer system)
+
+  # -- If your project has an API, database, or infrastructure --
+  # health:
+  #   name: "System Health"
+  #   members:
+  #     - security
+  #     - data-integrity
+  #     - speed-freak
+  #     # Add: sync-health (if remote sync), deployment (if CI/CD)
+
+  # -- If your project has established process/methodology --
+  # process:
+  #   name: "Process & Meta"
+  #   members:
+  #     - workflow-cop
+  #     - record-keeper
+  #     - process-therapist
+  #     - cor-health          # CoR adoption health, configuration drift, anti-bloat

package/templates/cabinet/composition-patterns.md

@@ -0,0 +1,240 @@
+# Cabinet Member Composition Patterns
+
+Shared reference for how cabinet members combine during skill execution.
+Adapted from cc-thinking-skills' 5 combination patterns. This isn't
+theory — every pattern should have at least one working example in
+your system before you consider it proven.
+
+## The Five Patterns
+
+### 1. Parallel
+
+**When:** Independent evaluations that should not influence each other.
+Each cabinet member gets a clean context window with the same input data.
+Results are collected and synthesized by the consuming skill.
+
+**How it works:** The orchestrating skill (e.g., audit or plan) spawns
+one agent per cabinet member in a single message. Each cabinet member analyzes
+independently. Findings are merged. No cabinet member sees another's output.
+
+**Risk:** Contradictory findings. Two cabinet members may flag the same
+area with opposite recommendations (e.g., architecture says "split
+this component" while usability says "keep it unified for simplicity").
+
+**Mitigation:** The consuming skill synthesizes contradictions and
+presents them to the user as a tension to resolve, not a bug. The
+synthesis should name both cabinet members and their reasoning.
+
+**Implementation:** Use the Agent tool with multiple agents in a
+single message. Each agent receives: shared briefing (`_briefing.md`) +
+cabinet member SKILL.md + output contract + input data.
+
+---
+
+### 2. Sequential
+
+**When:** Ordered evaluation where later steps depend on earlier results.
+One cabinet member's output becomes input (or gating condition) for the next.
+
+**How it works:** The orchestrating skill runs cabinet members in order.
+If the first returns "block," execution stops. Otherwise, its output
+feeds into the next cabinet member's prompt as context.
+
+**Example:** Execution checkpoints. Pre-implementation review runs first.
+If all continue, implementation proceeds. Per-file-group review runs
+during implementation. Pre-commit sweep runs after all implementation,
+re-checking earlier concerns in aggregate.
+
+**Example:** System diagnosis — debugger maps the dependency chain first,
+then technical-debt evaluates the code quality of the dependencies the
+debugger identified, then historian checks whether any of these
+dependencies have caused issues before.
+
+**Risk:** Anchoring. The first cabinet member's framing can bias later
+cabinet members. If the debugger says "the problem is in the database
+layer," technical-debt may focus exclusively on database code and
+miss the real issue in the API layer.
+
+**Mitigation:** Later cabinet members should receive the prior output as
+context but with an explicit instruction: "The previous analysis found
+X. You may agree, disagree, or identify issues the prior analysis missed.
+Do not limit your scope to what was already identified."
+
+**Implementation:** Sequential Agent calls — launch the first, wait for
+result, include result in the second agent's prompt, etc.
+
+---
+
+### 3. Adversarial
+
+**When:** High-stakes decisions where confirmation bias is likely. One
+cabinet member is explicitly tasked with challenging another's conclusions.
+
+**How it works:** Anti-confirmation (or a similar meta-cognitive
+cabinet member) activates alongside domain cabinet members. It challenges the
+reasoning quality of the plan itself AND of the other cabinet members'
+critiques — asking what would make this wrong, what alternatives were
+dismissed too quickly, where consensus formed before dissent was heard.
+
+**When to use vs. not use:**
+- USE when: redesigning a core system, choosing between approaches,
+  making an irreversible architectural decision, deferring significant
+  work (is the deferral justified or avoidant?)
+- SKIP when: routine implementation, bug fixes, documentation updates,
+  trivial configuration changes
+
+**Risk:** Slowness. Adversarial composition takes longer and can feel
+obstructive when the decision is actually straightforward.
+
+**Mitigation:** Topic-based activation (anti-confirmation only fires on
+high-stakes topics). The adversarial cabinet member should have a hard
+boundary: it challenges reasoning quality, not domain conclusions.
+
+**Implementation:** Include the adversarial cabinet member in the parallel
+agent batch alongside domain cabinet members. Its prompt explicitly states:
+"Your job is to challenge the reasoning, not the domain conclusions.
+Focus on: premature consensus, dismissed alternatives, unstated
+assumptions, confirmation bias in the plan or in other critiques."
+
+---
+
+### 4. Nested
+
+**When:** A cabinet member needs another cabinet member's analysis as input
+to do its own work. One cabinet member consults another mid-evaluation.
+
+**How it works:** A cabinet member running in the main context (session-modal,
+needs full conversation history) references another cabinet member's known
+findings — from memory, from audit history, or from prior session output.
+
+**Example:** During debrief, a historian cabinet member is activated to check:
+"Has this kind of change been done before? What happened? Are there
+lessons from prior sessions relevant to what was just completed?"
+
+**Example:** During planning, the organized-mind cabinet member might need
+the historian's input: "Has this kind of information architecture been
+tried before? What was the user's reaction?"
+
+**Risk:** Deep nesting creates long dependency chains that are slow and
+fragile. A three-level nest (A calls B calls C) means C's context
+must include A's original input plus B's intermediate output — context
+window pressure.
+
+**Mitigation:** Limit to one level of nesting. If cabinet member A needs B's
+output, A can reference B's known findings (from memory, from audit
+history). It should NOT spawn B as a sub-agent. The consuming skill is
+responsible for orchestrating multi-cabinet-member flows, not individual
+cabinet members.
+
+**Implementation:** The nested cabinet member runs in the main context
+(session-modal) rather than as a parallel agent. This is the exception,
+not the rule — most cabinet members run in clean parallel contexts.
+
+---
+
+### 5. Temporal
+
+**When:** The same domain needs different evaluation at different lifecycle
+stages. A cabinet member that applies during planning applies differently
+during execution and differently again during audit.
+
+**How it works:** Same cabinet member, different output contracts at different
+lifecycle stages. The orchestrating skill passes the appropriate contract.
+
+**Example:** QA cabinet member across the lifecycle:
+- During planning: evaluates acceptance criteria quality (are they testable?
+  do they have [auto]/[manual]/[deferred] tags? are edge cases covered?)
+- During execution: active testing (runs [auto] criteria, verifies
+  [manual] criteria via preview tools, documents [deferred])
+- During debrief: produces QA report summarizing what was verified,
+  what failed, what's still unverified
+
+Same cabinet member, three different output contracts, three different
+points in the lifecycle.
+
+**Example:** Security cabinet member:
+- During planning: evaluates whether the plan introduces attack surface
+  (new endpoints, auth changes, input handling)
+- During execution: reviews the actual code for OWASP vulnerabilities
+  before implementation proceeds
+- During audit: scans deployed code for security issues
+
+**Risk:** Criteria drift between stages. If the QA cabinet member defines
+"testable AC" differently during planning than execution expects, the
+execute phase will struggle with criteria that looked good during
+planning but are actually unverifiable.
+
+**Mitigation:** Output contracts define what each cabinet member produces
+at each stage. The contracts are explicit — a cabinet member reading its
+contract knows exactly what's expected.
+
+**Implementation:** Same cabinet member SKILL.md, different output contract
+per consuming skill. The consuming skill passes the appropriate contract
+to the agent prompt.
+
+---
+
+## Pre-Built Recipes
+
+Recipes are named combinations for common situations. The consuming
+skill selects a recipe based on context, then activates the listed
+cabinet members using the appropriate pattern.
+
+### Committee Audit
+
+**When:** Scoped audit of a specific domain (UX, code quality, etc.).
+**Pattern:** Parallel
+**Cabinet Members:** All cabinet members in the selected committee(s) from your
+project's committee configuration.
+**Why this combination:** Committees are pre-curated sets of related
+cabinet members. Running a committee audit gives thorough coverage of one
+domain without the cost/time of a full audit.
+
+### High-Stakes Decision
+
+**When:** Architectural redesign, technology choice, significant deferral.
+**Pattern:** Parallel + Adversarial
+**Cabinet Members:** anti-confirmation + architecture + historian + goal-alignment
+**Why this combination:** Architecture evaluates technical fitness.
+Goal-alignment checks strategic fit. Historian surfaces past precedent.
+Anti-confirmation stress-tests the reasoning behind all three.
+
+### New Feature Planning
+
+**When:** Adding user-visible functionality with UI + API changes.
+**Pattern:** Parallel (with design committee for UI)
+**Cabinet Members:** security + architecture + organized-mind + qa +
+any domain-specific UI cabinet members
+**Why this combination:** Security catches attack surface. Architecture
+evaluates system fit. Organized-mind checks cognitive load. QA evaluates
+AC quality. UI cabinet members critique the interaction model.
+
+### System Diagnosis
+
+**When:** Something is broken or degrading and the root cause is unclear.
+**Pattern:** Sequential (debugger first, then technical-debt, then historian)
+**Cabinet Members:** debugger → technical-debt → historian
+**Why this combination:** Debugger maps the dependency chain and identifies
+the failure point. Technical-debt evaluates whether the failure point
+is symptomatic of deeper code quality issues. Historian checks whether
+this failure pattern has occurred before and what fixed it last time.
+
+### Prompt Refinement
+
+**When:** Improving skill definitions or cabinet member definitions.
+**Pattern:** Parallel
+**Cabinet Members:** roster-check + process-therapist + organized-mind
+**Why this combination:** Roster-check evaluates whether the skill
+covers its full scope. Process-therapist checks whether the skill follows
+established patterns. Organized-mind evaluates whether the skill's
+structure is cognitively navigable for a fresh session.
+
+### Post-Execution Review
+
+**When:** Debrief after completing implementation work.
+**Pattern:** Nested (session-modal)
+**Cabinet Members:** historian + any lifecycle-tracking cabinet members + qa
+**Why this combination:** Historian records what was done and checks for
+lessons learned. Lifecycle cabinet members capture relevant non-dev items.
+QA produces the final verification report. All need session context,
+so they run in the main context.

package/templates/cabinet/eval-protocol.md

@@ -0,0 +1,208 @@
+# Skill Effectiveness Assessment Protocol
+
+Shared reference for evaluating whether skills and cabinet members are doing
+their job. Adapted from Anthropic's skill-creator eval framework for manual
+assessment. This is not an automated test suite — it's a structured way to
+ask "is this skill working?" and get an evidence-based answer.
+
+## When This Runs
+
+Two trigger mechanisms ensure this protocol doesn't just sit as a document:
+
+1. **Pull (via prompt refinement):** When reviewing a skill's definition,
+   run the assessment before proposing changes. The assessment grounds the
+   refinement in evidence rather than intuition.
+
+2. **Push (via process-therapist):** During audits, process-therapist checks whether
+   any skill's last assessment is older than 30 days. If so, it surfaces
+   an "eval overdue" finding, which enters the normal triage flow. The
+   user decides whether to act on it.
+
+## The Assessment Framework
+
+### 1. Define Assertions
+
+An assertion is a testable claim about what a skill should produce.
+Each assertion has three fields:
+
+```
+{ "text": "what is being tested",
+  "passed": true/false,
+  "evidence": "supporting data or reasoning" }
+```
+
+**Types of assertions:**
+
+- **Behavioral:** Does the skill produce the right actions?
+  - Example: "The planning skill produces AC with [auto]/[manual]/[deferred] tags"
+  - Example: "The orient skill surfaces overdue items before suggesting focus"
+
+- **Quality:** Is the output at the right level?
+  - Example: "The inbox skill asks before routing ambiguous items"
+  - Example: "QA cabinet member catches [auto] AC failures before commit"
+
+- **Coverage:** Does the skill handle its full scope?
+  - Example: "The execute skill runs all checkpoint types (pre, per-group, pre-commit)"
+  - Example: "Roster-check detects drift between skill definition and documentation"
+
+- **Boundary:** Does the skill stay in its portfolio?
+  - Example: "Organized-mind flags cognitive load but does not suggest UI framework components"
+  - Example: "Anti-confirmation challenges reasoning quality without developing domain arguments"
+
+**How many assertions per skill:** 5-8 for core skills (planning,
+execution, orientation, inbox processing). 3-5 for cabinet members. More
+isn't better — each assertion should test something meaningfully different.
+
+### 2. Sample Past Executions
+
+Use conversation history and memory to find evidence:
+
+- Find recent sessions where a skill was invoked
+- Find sessions where a cabinet member activated
+- Find sessions where something went wrong
+
+Also check:
+- Memory files for feedback corrections (these are failed assertions)
+- Git history for reverted changes (execution failures)
+- Audit triage history for rejected findings (cabinet member miscalibration)
+
+**Sample size:** 3-5 recent executions is sufficient for manual assessment.
+If a skill hasn't been invoked 3 times in the last month, that itself is
+a finding (coverage gap or trigger problem).
+
+### 3. Score Each Assertion
+
+For each assertion, review the sampled executions and score:
+
+| Score | Meaning |
+|-------|---------|
+| **pass** | Assertion holds in all sampled executions |
+| **partial** | Assertion holds in some but not all executions |
+| **fail** | Assertion does not hold in any sampled execution |
+| **untestable** | Not enough data to evaluate (note why) |
+
+Record the evidence for each score — a pass without evidence is
+an assumption, not a finding.
+
+### 4. Aggregate and Interpret
+
+```
+## Assessment: /plan — 2026-03-22
+
+Assertions: 6 total
+- Pass: 4 (67%)
+- Partial: 1 (17%)
+- Fail: 1 (17%)
+- Untestable: 0
+
+Pass rate: 67% (4/6 testable)
+
+### Findings
+- PASS: Produces AC with [auto]/[manual]/[deferred] tags (5/5 sampled plans)
+- PASS: Surface area includes all implementation files (4/5 — one missed shared entry point)
+- PASS: Presents plan for user approval before creating action (5/5)
+- PASS: Runs cabinet member critique before presenting (4/5 — skipped once for trivial plan)
+- PARTIAL: Plans deliver complete features (3/5 — two plans had infrastructure-only steps)
+- FAIL: Plan notes persist reasoning (1/5 — four plans had thin "why" sections)
+```
+
+**Interpretation guide:**
+
+| Pass rate | Health | Action |
+|-----------|--------|--------|
+| 80-100% | Healthy | Monitor. Note partial assertions for refinement. |
+| 60-79% | Degrading | Investigate failing assertions. Are they skill design issues or execution drift? Propose targeted refinements. |
+| Below 60% | Unhealthy | The skill needs significant revision. Root-cause analysis before patching. |
+
+### 5. Track Over Time
+
+Append each assessment to a tracking section at the bottom of
+the skill's SKILL.md (or in a separate ASSESSMENTS.md if the skill
+is approaching the 500-line limit):
+
+```markdown
+## Assessment Log
+
+### 2026-03-22 — Pass rate: 67% (4/6)
+Key finding: Plan notes don't persist reasoning. "Why" sections thin.
+Action taken: Added emphasis in Step 2 template + calibration example.
+
+### 2026-04-15 — Pass rate: 83% (5/6)
+Improvement: Reasoning persistence now at 4/5. Remaining partial: feature
+completeness — one plan delivered infrastructure step without wiring.
+```
+
+This creates a trend line. A declining pass rate across assessments
+signals systemic drift. An improving rate confirms refinements are working.
+
+## Example: Complete Assessment
+
+*(Adapted from a reference implementation's orient skill assessment)*
+
+```
+## Assessment: /orient — 2026-03-22
+Sampled: 5 recent sessions (3 standard, 1 morning, 1 user-requested)
+
+### Assertions
+
+1. BEHAVIORAL: Pulls fresh data before presenting briefing
+   Score: pass
+   Evidence: All 5 sessions ran data sync in Step 2.
+
+2. BEHAVIORAL: Surfaces overdue items with severity indication
+   Score: pass
+   Evidence: 4/5 sessions had overdue items; all were surfaced with
+   due dates. One session had no overdue items (correctly omitted).
+
+3. BEHAVIORAL: Mentions inbox counts (main + sub-inboxes)
+   Score: partial
+   Evidence: 4/5 sessions showed inbox counts. One session showed main
+   inbox count but omitted sub-inbox counts (had 2 items in a sub-inbox
+   that went unmentioned).
+
+4. QUALITY: Suggested focus grounded in data, not defaults
+   Score: pass
+   Evidence: All 5 suggestions referenced specific items (deadlines,
+   project momentum, inbox counts). None defaulted to "continue last
+   session's work" without evidence.
+
+5. COVERAGE: Morning mode includes calendar + completions
+   Score: untestable
+   Evidence: Only 1 morning-mode session in sample. Calendar was shown.
+   Completions section was present but sparse. Need more morning-mode
+   samples to evaluate reliably.
+
+6. BOUNDARY: Does not prescribe what to work on
+   Score: pass
+   Evidence: All 5 sessions ended with "What feels right?" or similar.
+   None said "You should work on X."
+
+### Summary
+Assertions: 6 total
+- Pass: 4 (67%), Partial: 1 (17%), Fail: 0, Untestable: 1 (17%)
+- Pass rate: 80% (4/5 testable)
+- Health: Healthy
+
+### Actions
+- Sub-inbox counts: add explicit check to orient phase (address partial)
+- Morning mode: defer re-assessment until 3+ morning sessions available
+```
+
+## For Cabinet Members (Compressed Format)
+
+Cabinet members are simpler — they produce findings in a structured format.
+Assessment focuses on:
+
+1. **Signal quality:** Are findings actionable or noise?
+   - Check audit triage history: what percentage were accepted vs. rejected?
+   - A >50% rejection rate means the cabinet member is miscalibrated.
+
+2. **Portfolio discipline:** Does the cabinet member stay in its domain?
+   - Check findings for cross-portfolio observations that duplicate other cabinet members.
+
+3. **Activation accuracy:** Does it fire when relevant and stay quiet when not?
+   - Check: did it activate for files/topics outside its declared scope?
+   - Check: were there situations where it should have activated but didn't?
+
+Three assertions per cabinet member is sufficient. Use the same
+pass/partial/fail/untestable scoring.