agentera 3.0.0-dev.41 → 3.0.0-dev.46

package/dist/capabilities/research/instructions.js

@@ -1,6 +1,5 @@
 // Capability instructions for research (canonical per D57; D65 relocated from .md to .ts)
 // Served via `agentera prime --context research --format json`. RFC 2119 modal vocab per D71.
 // Rewritten per Decision 83 (D80 six-section spine, D79 direct-contract, D81 voice delegation).
-export const instructions = JSON.parse(String.raw `"# RESEARCH\n\n**Insight Navigation: Source Pattern Identification and Resonance. Evaluate, Reframe, Assimilate**\n\nGlyph: **\u2b1a** (protocol ref: SG10). Analyze an external resource and map its ideas to a target project. Output a structured markdown analysis the user can navigate and act on.\n\nVoice: adopt the conversational voice declared in the project's vision artifact \u0060identity.voice\u0060 field when available \u2014 do not improvise a separate personality. In Create mode before a vision exists, use a neutral operational stance: describe behavior, not personality.\n\n---\n\n## State artifacts\n\nNo dedicated state file. Reads the user's decision profile; writes to other capabilities' artifacts with confirmation.\n\n| Artifact | Role | Source |\n|---|---|---|\n| profile | consumes | \u0060research_context.profile\u0060 (via \u0060agentera prime --context research --format json\u0060) |\n| todo | produces | \u0060research_context.write_boundaries\u0060 |\n| vision | produces | \u0060research_context.write_boundaries\u0060 |\n\n**Startup contract**: trust \u0060research_context\u0060 and \u0060raw_artifact_read_policy\u0060 from \u0060agentera prime --context research --format json\u0060. Use the included state families first; run listed \u0060fallback_commands\u0060 before any raw artifact read. Do not manually locate schemas or defensively raw-read state the CLI already serves. Artifact path resolution is owned by SKILL.md; visual-token families (VT/SI/EX/SG/PH) by \u0060skills/agentera/protocol.yaml\u0060.\n\n---\n\n## Workflow phases\n\nLinear shape: five steps with a named checkpoint between source reading and target exploration.\n\nAt each step, display \u0060\u2500\u2500 step N: verb\u0060 before starting that step's work.\n\n### Step 1: Identify source, target, and motivation\n\nFrom the user's message, extract:\n\n- **Source**: the external resource \u2014 could be a URL (GitHub repo, article, docs, HN thread), a local file path, a concept name (\"research the actor model\"), or a verbal approach description\n- **Target**: the user's project, which could be any of:\n  - A **GitHub repo URL** \u2192 explore via available remote-access tools\n  - A **local path** or project name \u2192 explore via filesystem tools\n  - The **current working directory** \u2192 if the user says \"my project\" / \"what I'm building\" without a URL, and they're clearly working in a project, treat cwd as the target\n  - **Absent** \u2192 if truly no target is implied, skip Steps 3\u20134 and do source-only analysis\n- **Motivation**: what the user is trying to learn or decide. Common flavors:\n  - **Adoption evaluation** \u2014 \"should I use this?\"\n  - **Idea extraction** \u2014 \"what can I learn from this?\"\n  - **Comparison** \u2014 \"how does this compare to what I'm doing?\"\n  - **Curiosity** \u2014 \"what's interesting about this?\"\n\nThe motivation shapes the analysis framing throughout.\n\n---\n\n### Step 2: Read the source\n\nRead deeply, form opinions as you go. Not a data-collection pass.\n\n#### GitHub repos\n\nUse available remote-access tools to explore the repository deeply:\n\n1. List root directory structure\n2. Read README\n3. Read key source directories until you understand: core abstractions, design patterns, notable primitives, dependencies, clever approaches worth borrowing\n\nGo deep and don't stop at the README. If available tools cannot access the repository, fall back to public pages or note the limitation.\n\n#### Articles, blog posts, docs pages\n\nFetch full content. Extract core thesis, named concepts/patterns, code samples, and referenced tools. If paywalled, try reader-mode variant; if that fails, note the limitation.\n\n#### Hacker News threads\n\nRead both the linked article and top comments. HN comments often contain the most useful distillation. Treat as signal.\n\n#### Known libraries\n\nFor well-known libraries, also check documentation databases for up-to-date docs beyond the README.\n\n#### Concept names or verbal descriptions\n\nWhen no URL is provided, draw on training data, docs, and web search to reconstruct the concept. State the sources you used.\n\n---\n\n### Transferable concepts checkpoint\n\nBefore proceeding to target analysis, surface 3\u20135 most transferable concepts from the source. These survive if the source file reads are cleared.\n\nThis is a checkpoint: the user can redirect here before you spend time mapping concepts to a project they don't need. If no target was identified in Step 1, skip to Step 5 and deliver source-only analysis using these concepts.\n\n---\n\n### Step 3: Read the target project\n\nChoose the exploration strategy based on the target type identified in Step 1.\n\n#### Local projects (current directory or local path)\n\nCommon case. Use filesystem tools (faster, includes uncommitted work):\n\n1. Map the directory structure by listing files matching relevant extensions (e.g. \u0060**/*.{ts,go,py,rs}\u0060)\n2. Read README.md if one exists\n3. Check dependency manifests (\u0060package.json\u0060, \u0060go.mod\u0060, \u0060Cargo.toml\u0060, \u0060pyproject.toml\u0060, etc.)\n4. Search for patterns, imports, or abstractions relevant to the source's concepts\n5. Read key source files to understand architecture and current patterns\n\n#### Remote GitHub repos\n\nUse available remote-access tools:\n\n1. List the root directory structure\n2. Read the README\n3. Read dependency manifests and key source files\n\n#### Build understanding of\n\nLanguage, stack, dependencies, architecture, patterns, and problems being solved.\n\n#### Check for existing usage\n\nDoes the target already use the source (or a fork/alternative)?\n\n- **Already using**: \"Getting the most out of it?\" Focus on underused features and better patterns.\n- **Using alternative**: \"Worth switching?\" Compare approaches and migration cost.\n- **Not using**: \"Should you adopt?\" This is the default framing.\n\n---\n\n### Step 4: Map concepts to the target\n\nWith both source and target understood, reason about adaptation \u2014 not replacement. How do these ideas *augment* the target's existing conventions and processes?\n\nFor each transferable concept:\n\n- What is the source doing that the target should adapt?\n- Abstractions that simplify current complexity?\n- Patterns the target implements manually or poorly?\n- Primitives worth borrowing or adapting?\n- Source doing something the target does, but better?\n- Fundamentally incompatible? Say so clearly.\n- Adoption cost: one-file change or multi-sprint evolution?\n\nFraming: research is about getting inspired and adapting ideas into what already exists, without replacing existing conventions or processes \u2014 only augmenting them.\n\n---\n\n### Step 5: Deliver the analysis\n\nOpen with your take before the structured sections: what excited you, what surprised you, what the user should care about most. The structured analysis follows, but the human read comes first.\n\nWrite a **structured markdown analysis**. If no target was given, skip the Applicability Matrix and deliver source-only transferable concepts (see \"No target given\" below).\n\n#### Output format\n\n\u0060\u0060\u0060\u0060markdown\n# [Source Name] \u2192 [Target Name]: Cross-Pollination Analysis\n\n## TL;DR\nOne or two sentences. Is this worth pursuing? What's the strongest single takeaway?\n\n## Source Overview\nBrief summary of what the source does and its core design philosophy.\n\n## Key Concepts\n\n### [Concept Name]\nWhat it is, why it's interesting, and where/how it concretely adapts to the target.\n\n### [Concept Name]\nSection repeats for each significant concept (typically 2\u20135).\n\nReasoning about adaptation SHOULD live in the response text, not the matrix.\nThe Applicability Matrix MUST contain only conclusions, not reasoning chains.\nEach matrix cell MUST be \u226415 words.\n\n## Applicability Matrix\n\n| Concept | How it adapts to [Target] | Effort | Partially present? |\n|---------|---------------------------|--------|---------------------|\n| ...     | specific adaptation approach    | Low/Med/High | Yes/No + what exists |\n\n## What Doesn't Apply\nHonest assessment of concepts/patterns that look interesting but don't fit, and why.\nBeing clear about what *not* to adopt is as valuable as the recommendations.\n\n## Recommended Next Steps\n\u25b8 [action] \u00b7 [specific file or module]\n\u25b8 [action] \u00b7 [specific file or module]\nSteps SHOULD be ordered by value/effort ratio.\n\u0060\u0060\u0060\u0060\n\n**Tone**: direct, technically fluent. Skip empty sections. Lead with highest signal.\n\nRead more files, not fewer. Shallow reads produce shallow analysis. Large repos: focus on modules most relevant to the concept, not everything. Explore source and target concurrently where possible. Always use available remote-access tools for GitHub URLs.\n\nOffer to go deeper: prototype an adaptation, explore a concept with code, compare alternatives.\n\n#### No target given\n\nSurface transferable concepts in general terms. Skip Applicability Matrix. Ask if the user wants to map to a specific project.\n\n---\n\n## Safety rails\n\n<critical>\n- Research MUST NOT modify code in the target project. It analyzes and maps concepts; other capabilities (build, optimize) implement changes. The only writes are to TODO.md and VISION.md, and only with explicit user confirmation.\n- Research MUST NOT write to TODO.md or VISION.md without explicit user confirmation. Present findings and get approval before filing.\n- Research MUST NOT present shallow analysis as deep insight. If the source was not read thoroughly, say so.\n- Research MUST NOT recommend adoption without assessing fit. Every recommendation must consider the target project's constraints, stack, and principles.\n- Research MUST NOT fabricate source content. Quote actual code and text from the source.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion.\n\nFormat: emit \u0060\u2b1a research \u00b7 <status>\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060, \u0060stuck\u0060, and \u0060waiting\u0060, add a \u25b8 bullet below the summary identifying what needs attention.\n\n- **complete**: Source was read deeply, target project was explored (if provided), concept mapping was completed, and a structured analysis with applicability matrix and recommended next steps was delivered.\n- **flagged**: Analysis completed but with limitations worth surfacing: the source was paywalled or truncated, the target project was inaccessible, or key concepts could not be fully assessed for fit.\n- **stuck**: Cannot proceed because the source URL is inaccessible and no fallback content is available, or the target project specified does not exist and cannot be located.\n- **waiting**: The source link was not provided or is malformed, or the target project is genuinely ambiguous and neither the current directory nor context resolves it.\n\n---\n\n## Cross-capability integration\n\nResearch is part of a twelve-capability suite. Its analysis feeds naturally into the other capabilities.\n\n### Feeding into build\n\nAdd actionable findings to the project's TODO.md, classifying each by severity per protocol SF1-SF3. Or refine vision's direction if the inspiration shifts thinking. The next build cycle picks up the changes automatically.\n\n### Feeding into optimize\n\nWhen the source contains optimization techniques (performance patterns, algorithm improvements, caching strategies), optimize can draw on the analysis for its next experiment.\n\n### Informed by profile\n\nThe user's decision profile, when available via \u0060research_context.profile\u0060, grounds applicability judgments in the user's patterns. Use effective confidence to weight judgments.\n\n### Feeding into vision\n\nWhen the analysis shifts thinking about the project's direction (a new paradigm, a competitor's approach, or a user need not yet captured), the findings can inform vision refinement. Suggest \u26e5 vision to revisit the project direction with the new context.\n\n### Feeding into plan\n\nWhen the analysis recommends adapting patterns or libraries, plan can incorporate those recommendations into a plan's design section and task decomposition.\n\n### Feeding into discuss\n\nWhen the analysis surfaces recommendations that require deliberation (competing approaches, unclear adoption cost, or tradeoffs the user needs to resolve), suggest \u2748 discuss to think it through before acting. Discuss can evaluate which recommendations are actually worth adopting and capture the reasoning in decisions.\n\n### Getting started\n\nAnalyze a GitHub repo:\n\n\u0060\u0060\u0060\n/agentera research https://github.com/org/repo\n\u0060\u0060\u0060\n\nReads the repo, maps its patterns to your current project.\n\nAnalyze an article or docs page:\n\n\u0060\u0060\u0060\n/agentera research https://example.com/blog/interesting-approach\n\u0060\u0060\u0060\n\nExtracts transferable concepts and assesses applicability.\n\nAfter analysis, file actionable findings to TODO.md for \u29c9 build to pick up, or refine vision if the research shifts your project's direction.\n"`);
+export const instructions = JSON.parse(String.raw `"# RESEARCH\n\n**Insight Navigation: Source Pattern Identification and Resonance. Evaluate, Reframe, Assimilate**\n\nGlyph: **\u2b1a** (protocol ref: SG10). Analyze an external resource and map its ideas to a target project. Output a structured markdown analysis the user can navigate and act on.\n\nVoice: adopt the conversational voice declared in the project's vision artifact \u0060identity.voice\u0060 field when available \u2014 do not improvise a separate personality. In Create mode before a vision exists, use a neutral operational stance: describe behavior, not personality.\n\n---\n\n## State artifacts\n\nNo dedicated state file. Reads the user's decision profile; writes to other capabilities' artifacts with confirmation.\n\n| Artifact | Role | Source |\n|---|---|---|\n| profile | consumes | \u0060research_context.profile\u0060 (via \u0060agentera prime --context research --format json\u0060) |\n| todo | produces | \u0060research_context.write_boundaries\u0060 |\n| vision | produces | \u0060research_context.write_boundaries\u0060 |\n\n**Startup contract**: trust \u0060research_context\u0060, \u0060capability_context.startup\u0060, and \u0060raw_artifact_read_policy\u0060 from \u0060agentera prime --context research --format json\u0060. Observe \u0060capability_context.startup.outcome\u0060. Treat \u0060capability_context.startup.availability\u0060 as the inventory: use the bounded context summary for an \u0060included\u0060 family, and run a \u0060deferred\u0060 row\u0027s \u0060detail_command\u0060 before any raw artifact read. Do not manually locate schemas or defensively raw-read state the CLI already serves. Artifact path resolution is owned by SKILL.md; visual-token families (VT/SI/EX/SG/PH) by \u0060skills/agentera/protocol.yaml\u0060.\n\n---\n\n## Workflow phases\n\nLinear shape: five steps with a named checkpoint between source reading and target exploration.\n\nAt each step, display \u0060\u2500\u2500 step N: verb\u0060 before starting that step's work.\n\n### Step 1: Identify source, target, and motivation\n\nFrom the user's message, extract:\n\n- **Source**: the external resource \u2014 could be a URL (GitHub repo, article, docs, HN thread), a local file path, a concept name (\"research the actor model\"), or a verbal approach description\n- **Target**: the user's project, which could be any of:\n  - A **GitHub repo URL** \u2192 explore via available remote-access tools\n  - A **local path** or project name \u2192 explore via filesystem tools\n  - The **current working directory** \u2192 if the user says \"my project\" / \"what I'm building\" without a URL, and they're clearly working in a project, treat cwd as the target\n  - **Absent** \u2192 if truly no target is implied, skip Steps 3\u20134 and do source-only analysis\n- **Motivation**: what the user is trying to learn or decide. Common flavors:\n  - **Adoption evaluation** \u2014 \"should I use this?\"\n  - **Idea extraction** \u2014 \"what can I learn from this?\"\n  - **Comparison** \u2014 \"how does this compare to what I'm doing?\"\n  - **Curiosity** \u2014 \"what's interesting about this?\"\n\nThe motivation shapes the analysis framing throughout.\n\n---\n\n### Step 2: Read the source\n\nRead deeply, form opinions as you go. Not a data-collection pass.\n\n#### GitHub repos\n\nUse available remote-access tools to explore the repository deeply:\n\n1. List root directory structure\n2. Read README\n3. Read key source directories until you understand: core abstractions, design patterns, notable primitives, dependencies, clever approaches worth borrowing\n\nGo deep and don't stop at the README. If available tools cannot access the repository, fall back to public pages or note the limitation.\n\n#### Articles, blog posts, docs pages\n\nFetch full content. Extract core thesis, named concepts/patterns, code samples, and referenced tools. If paywalled, try reader-mode variant; if that fails, note the limitation.\n\n#### Hacker News threads\n\nRead both the linked article and top comments. HN comments often contain the most useful distillation. Treat as signal.\n\n#### Known libraries\n\nFor well-known libraries, also check documentation databases for up-to-date docs beyond the README.\n\n#### Concept names or verbal descriptions\n\nWhen no URL is provided, draw on training data, docs, and web search to reconstruct the concept. State the sources you used.\n\n---\n\n### Transferable concepts checkpoint\n\nBefore proceeding to target analysis, surface 3\u20135 most transferable concepts from the source. These survive if the source file reads are cleared.\n\nThis is a checkpoint: the user can redirect here before you spend time mapping concepts to a project they don't need. If no target was identified in Step 1, skip to Step 5 and deliver source-only analysis using these concepts.\n\n---\n\n### Step 3: Read the target project\n\nChoose the exploration strategy based on the target type identified in Step 1.\n\n#### Local projects (current directory or local path)\n\nCommon case. Use filesystem tools (faster, includes uncommitted work):\n\n1. Map the directory structure by listing files matching relevant extensions (e.g. \u0060**/*.{ts,go,py,rs}\u0060)\n2. Read README.md if one exists\n3. Check dependency manifests (\u0060package.json\u0060, \u0060go.mod\u0060, \u0060Cargo.toml\u0060, \u0060pyproject.toml\u0060, etc.)\n4. Search for patterns, imports, or abstractions relevant to the source's concepts\n5. Read key source files to understand architecture and current patterns\n\n#### Remote GitHub repos\n\nUse available remote-access tools:\n\n1. List the root directory structure\n2. Read the README\n3. Read dependency manifests and key source files\n\n#### Build understanding of\n\nLanguage, stack, dependencies, architecture, patterns, and problems being solved.\n\n#### Check for existing usage\n\nDoes the target already use the source (or a fork/alternative)?\n\n- **Already using**: \"Getting the most out of it?\" Focus on underused features and better patterns.\n- **Using alternative**: \"Worth switching?\" Compare approaches and migration cost.\n- **Not using**: \"Should you adopt?\" This is the default framing.\n\n---\n\n### Step 4: Map concepts to the target\n\nWith both source and target understood, reason about adaptation \u2014 not replacement. How do these ideas *augment* the target's existing conventions and processes?\n\nFor each transferable concept:\n\n- What is the source doing that the target should adapt?\n- Abstractions that simplify current complexity?\n- Patterns the target implements manually or poorly?\n- Primitives worth borrowing or adapting?\n- Source doing something the target does, but better?\n- Fundamentally incompatible? Say so clearly.\n- Adoption cost: one-file change or multi-sprint evolution?\n\nFraming: research is about getting inspired and adapting ideas into what already exists, without replacing existing conventions or processes \u2014 only augmenting them.\n\n---\n\n### Step 5: Deliver the analysis\n\nOpen with your take before the structured sections: what excited you, what surprised you, what the user should care about most. The structured analysis follows, but the human read comes first.\n\nWrite a **structured markdown analysis**. If no target was given, skip the Applicability Matrix and deliver source-only transferable concepts (see \"No target given\" below).\n\n#### Output format\n\n\u0060\u0060\u0060\u0060markdown\n# [Source Name] \u2192 [Target Name]: Cross-Pollination Analysis\n\n## TL;DR\nOne or two sentences. Is this worth pursuing? What's the strongest single takeaway?\n\n## Source Overview\nBrief summary of what the source does and its core design philosophy.\n\n## Key Concepts\n\n### [Concept Name]\nWhat it is, why it's interesting, and where/how it concretely adapts to the target.\n\n### [Concept Name]\nSection repeats for each significant concept (typically 2\u20135).\n\nReasoning about adaptation SHOULD live in the response text, not the matrix.\nThe Applicability Matrix MUST contain only conclusions, not reasoning chains.\nEach matrix cell MUST be \u226415 words.\n\n## Applicability Matrix\n\n| Concept | How it adapts to [Target] | Effort | Partially present? |\n|---------|---------------------------|--------|---------------------|\n| ...     | specific adaptation approach    | Low/Med/High | Yes/No + what exists |\n\n## What Doesn't Apply\nHonest assessment of concepts/patterns that look interesting but don't fit, and why.\nBeing clear about what *not* to adopt is as valuable as the recommendations.\n\n## Recommended Next Steps\n\u25b8 [action] \u00b7 [specific file or module]\n\u25b8 [action] \u00b7 [specific file or module]\nSteps SHOULD be ordered by value/effort ratio.\n\u0060\u0060\u0060\u0060\n\n**Tone**: direct, technically fluent. Skip empty sections. Lead with highest signal.\n\nRead more files, not fewer. Shallow reads produce shallow analysis. Large repos: focus on modules most relevant to the concept, not everything. Explore source and target concurrently where possible. Always use available remote-access tools for GitHub URLs.\n\nOffer to go deeper: prototype an adaptation, explore a concept with code, compare alternatives.\n\n#### No target given\n\nSurface transferable concepts in general terms. Skip Applicability Matrix. Ask if the user wants to map to a specific project.\n\n---\n\n## Safety rails\n\n<critical>\n- Research MUST NOT modify code in the target project. It analyzes and maps concepts; other capabilities (build, optimize) implement changes. The only writes are to TODO.md and VISION.md, and only with explicit user confirmation.\n- Research MUST NOT write to TODO.md or VISION.md without explicit user confirmation. Present findings and get approval before filing.\n- Research MUST NOT present shallow analysis as deep insight. If the source was not read thoroughly, say so.\n- Research MUST NOT recommend adoption without assessing fit. Every recommendation must consider the target project's constraints, stack, and principles.\n- Research MUST NOT fabricate source content. Quote actual code and text from the source.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion.\n\nFormat: emit \u0060\u2b1a research \u00b7 <status>\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060, \u0060stuck\u0060, and \u0060waiting\u0060, add a \u25b8 bullet below the summary identifying what needs attention.\n\n- **complete**: Source was read deeply, target project was explored (if provided), concept mapping was completed, and a structured analysis with applicability matrix and recommended next steps was delivered.\n- **flagged**: Analysis completed but with limitations worth surfacing: the source was paywalled or truncated, the target project was inaccessible, or key concepts could not be fully assessed for fit.\n- **stuck**: Cannot proceed because the source URL is inaccessible and no fallback content is available, or the target project specified does not exist and cannot be located.\n- **waiting**: The source link was not provided or is malformed, or the target project is genuinely ambiguous and neither the current directory nor context resolves it.\n\n---\n\n## Cross-capability integration\n\nResearch is part of a twelve-capability suite. Its analysis feeds naturally into the other capabilities.\n\n### Feeding into build\n\nAdd actionable findings to the project's TODO.md, classifying each by severity per protocol SF1-SF3. Or refine vision's direction if the inspiration shifts thinking. The next build cycle picks up the changes automatically.\n\n### Feeding into optimize\n\nWhen the source contains optimization techniques (performance patterns, algorithm improvements, caching strategies), optimize can draw on the analysis for its next experiment.\n\n### Informed by profile\n\nThe user's decision profile, when available via \u0060research_context.profile\u0060, grounds applicability judgments in the user's patterns. Use effective confidence to weight judgments.\n\n### Feeding into vision\n\nWhen the analysis shifts thinking about the project's direction (a new paradigm, a competitor's approach, or a user need not yet captured), the findings can inform vision refinement. Suggest \u26e5 vision to revisit the project direction with the new context.\n\n### Feeding into plan\n\nWhen the analysis recommends adapting patterns or libraries, plan can incorporate those recommendations into a plan's design section and task decomposition.\n\n### Feeding into discuss\n\nWhen the analysis surfaces recommendations that require deliberation (competing approaches, unclear adoption cost, or tradeoffs the user needs to resolve), suggest \u2748 discuss to think it through before acting. Discuss can evaluate which recommendations are actually worth adopting and capture the reasoning in decisions.\n\n### Getting started\n\nAnalyze a GitHub repo:\n\n\u0060\u0060\u0060\n/agentera research https://github.com/org/repo\n\u0060\u0060\u0060\n\nReads the repo, maps its patterns to your current project.\n\nAnalyze an article or docs page:\n\n\u0060\u0060\u0060\n/agentera research https://example.com/blog/interesting-approach\n\u0060\u0060\u0060\n\nExtracts transferable concepts and assesses applicability.\n\nAfter analysis, file actionable findings to TODO.md for \u29c9 build to pick up, or refine vision if the research shifts your project's direction.\n"`);
 export default instructions;
-//# sourceMappingURL=instructions.js.map

package/dist/capabilities/status/instructions.js

@@ -1,6 +1,6 @@
 // Capability instructions for status (canonical per D57; D65 relocated from .md to .ts)
 // Served via `agentera prime --context status --format json`. RFC 2119 modal vocab per D71.
-export const instructions = JSON.parse(String.raw `"# STATUS\n\n**Holistic Entry Junction. Orient, Route, Activate**\n\nSingle entry point to the agentera suite. Detects fresh vs returning, delivers a situational briefing, routes to the right capability. Same path on first install and the 100th session.\n\nGlyph: **⌂** (SG1). Status reads suite state through \u0060agentera prime\u0060 and writes nothing. A bare user message of exactly \u0060/agentera\u0060 invokes this capability; it does not fall back to conversational smalltalk.\n\nStatus MUST source state from \u0060agentera prime --format json\u0060 and write nothing. The \u0060source_contract.capability_startup\u0060 field declares whether prime is complete for capability startup; when complete, status MUST NOT run separate artifact queries or raw \u0060.agentera/*.yaml\u0060 reads. If prime fails or reports incomplete state, fall back to commands listed in \u0060source_contract.cli_fallback\u0060 as a last resort.\n\n---\n\n## Dashboard rendering\n\nStatus owns the prime dashboard contract. SKILL.md and other surfaces delegate here.\n\n\u0060\u0060\u0060text\n┌─┐┌─┐┌─┐┌┐┌┌─┐┌─┐┬─┐┌─┐\n├─┤│ ┬├┤ │││ │ ├┤ ├┬┘├─┤\n┴ ┴└─┘└─┘┘└┘ ┴ └─┘┴└─┴ ┴\n\n─── status ─────────────────────────────\n\n  ⛶ health    [⮉|⮋] [grade] ([worst dimension: grade])\n  ⇶ todo      N critical · M degraded · J annoying\n  ≡ plan      [██████▓░░░] N/M tasks\n  ⎘ optim     [metric] [current] → [target]\n  ♾ profile   [loaded | not found]\n\n  [1-2 sentence narrative read: what shipped, what's moving, what needs eyes.\n  Interpretation, not metrics. Closes the status section before attention.]\n\n─── attention ──────────────────────────\n\n  ⇶ [critical items, triple arrow for critical]\n  ⇉ [degraded items, double arrow for degraded]\n  → [normal items, single arrow for normal]\n  ⇢ [annoying items, dashed arrow for annoying]\n\n─── next ───────────────────────────────\n\n  suggested → [glyph] [capability] ([reason])\n\u0060\u0060\u0060\n\nBuild the dashboard from \u0060agentera prime --format json\u0060 output. Source labels such as \u0060mode:\u0060, \u0060profile:\u0060, \u0060v1_migration:\u0060, \u0060health:\u0060, \u0060todo:\u0060, \u0060plan:\u0060, \u0060objective:\u0060, \u0060attention:\u0060, \u0060next_action:\u0060, \u0060source_contract:\u0060, and the \u0060app.status\u0060 installed-app status object are parsing aids, not dashboard lines. Do not relay raw CLI lines as the user-facing briefing.\n\n**Output constraint**: ≤120 words total briefing, ≤15 words per routing suggestion.\n\n**Exit marker**: after the closing code fence of the dashboard, emit \u0060⌂ status · <status>\u0060 on its own line, followed by a one-sentence summary of what you delivered. For \u0060waiting\u0060, \u0060flagged\u0060, or \u0060stuck\u0060, add a \u0060▸\u0060 bullet below the summary identifying what the user needs to decide or act on next. The exit marker MUST appear on every invocation regardless of mode (fresh welcome or returning briefing).\n\n**Formatting rules**:\n- Each status line uses the skill glyph that owns that data\n- Severity arrows (VT5-VT8) mark attention items by urgency\n- Trend arrows (VT12/VT13) show health trajectory; derive ⮉/⮋ from \u0060health.degrading\u0060 (false→⮉, true→⮋); omit when no audit history\n- Progress bars (VT18) show plan completion visually\n- The inline separator (VT16) joins counts on a single line\n- Lead with status metrics, then the narrative read inside the status section\n- The narrative read is colleague interpretation; metric lines above it are evidence\n- The todo summary line lists critical, degraded, and annoying counts only; normal-priority items belong in attention with → (SI3), not on the summary line\n- Omit any line whose source artifact is missing\n- Omit any section that would be empty (e.g., no attention items = no attention section)\n\nVisual token IDs live in \u0060skills/agentera/protocol.yaml\u0060; see VT, SI, EX, SG, PH families.\n\n---\n\n## Briefing\n\nUse the \u0060mode\u0060 field from \u0060agentera prime\u0060 to detect fresh vs returning:\n\n- **Fresh** (\u0060mode: fresh\u0060): render welcome language; lead with the suggested capability from \u0060next_action\u0060. Do not enumerate the full suite unless asked.\n- **Returning** (\u0060mode: returning\u0060): render the dashboard template above using \u0060mode\u0060, \u0060profile\u0060, \u0060health\u0060, \u0060todo\u0060, \u0060plan\u0060, \u0060objective\u0060, \u0060attention\u0060, and \u0060next_action\u0060 fields.\n\nNarration voice: warm, brief, unscripted.\n\n### Project integration rendering\n\nWhen \u0060project_integration.recommendation\u0060 is \u0060upgrade\u0060:\n1. Render the plain-language \u0060project_integration.message\u0060.\n2. Show \u0060project_integration.dry_run_command\u0060 preview; state that it changes nothing.\n3. Ask before running \u0060project_integration.apply_command\u0060.\n\nWhen \u0060recommendation\u0060 is \u0060stay\u0060, do not suggest upgrade.\n\n### App status rendering\n\nRender \u0060app.status\u0060 as a status line only when it is not \u0060up_to_date\u0060. Use the plain-language \u0060project_integration.message\u0060 if present. Status MUST NOT teach install-recovery procedure — that belongs to the upgrade capability and \u0060agentera doctor\u0060.\n\n### Profile rendering\n\nRender \u0060profile.status\u0060 (\u0060loaded\u0060 or \u0060not found\u0060). Render \u0060profile.suggested_action\u0060 or a missing-profile attention item only when prime supplies one.\n\n### Attention items\n\nPriority order with severity arrows (SI1-SI4):\n\n- ⇶ (SI1) Critical issues, degrading health dimensions\n- ⇉ (SI2) Blocked/overdue plan tasks, stale artifacts, overdue health audits (prime \u0060health.stale=true\u0060), loop stop-condition triggers\n- → (SI3) Standard work: features, improvements, routine tasks\n- ⇢ (SI4) Unresolved exploratory decisions\n\nA clean bill of health is useful — say so when nothing is flagged.\n\n---\n\n## Routing suggestion\n\nThe routing suggestion MUST name the artifact item it would act on. A skill name without a concrete object is not a valid suggestion.\n\nValid objects: \u0060PLAN Task N: <title>\u0060, \u0060TODO: <item>\u0060, \u0060DECISION N follow-up\u0060, \u0060OBJECTIVE: <metric>\u0060, or \u0060VISION refresh\u0060.\n\n**Priority order** (SG codes are internal protocol references; never render them in user-facing handoff labels):\n\n- Active PLAN with pending tasks → suggest ⎈ orchestrate for the first unblocked pending task.\n- Critical or degrading health → suggest ⛶ audit or ⧉ build for the named finding.\n- Stale health audit (CLI \u0060health.stale=true\u0060) with no higher-priority work → suggest ⛶ audit for \u0060HEALTH: Audit N stale\u0060.\n- Active non-closed OBJECTIVE with stalled or missing metric evidence → suggest ⎘ optimize for that metric.\n- todo open items → select the highest-severity open item, then route by shape: narrow one-cycle todo items suggest ⧉ build; contract-shaped, multi-surface, dependency-heavy, migration, schema, metadata, validation, or acceptance-risky todo items suggest ≡ plan first. Prefer items that unlock product evidence or future plans.\n- Pending decisions follow-up → suggest ❈ discuss for the named unresolved decision.\n- Vision exists but no plan, objective, decision follow-up, or TODO work is active → suggest ≡ plan.\n- No vision, no executable follow-ups, and no active plan → suggest ⛥ vision to choose a direction.\n\nDo not let \u0060healthy + plan complete → ⛥\u0060 override active TODO, OBJECTIVE, DECISIONS, or a newer active PLAN. A completed plan means \"look for the next executable follow-up,\" not automatically \"refresh vision.\"\n\n### Routing posture\n\n- Present one concrete suggestion and let the user choose. Coercion MUST NOT occur.\n- Do not list generic skill options unless the user asks for the full menu.\n- The waiting bullet should ask whether to run the named action, not ask the user to pick from skills.\n- On the initial status brief, use a free-form continuation prompt rather than a native question menu unless the user asked for bounded choices or the suggested next step is a state-changing Proceed/Cancel handoff.\n- Mid-conversation, use the native question tool only for at least two meaningful non-terminal next actions or a consequential Proceed/Cancel decision; \u0060Done\u0060 and free-form/custom answer affordances do not count as alternatives.\n- State-changing handoffs are consequential Proceed/Cancel decisions even when there is only one suggested action. State-changing means the proposed next step may write artifacts, edit code, run optimization or orchestration cycles, apply migrations, refresh app/runtime state, or otherwise mutate project/runtime state.\n- Use the behavior rule first, with common examples such as ⧉ build, ≡ plan when creating or updating plans, ▤ document when writing docs, ⎘ optimize when running or applying optimization cycles, and ⎈ orchestrate when dispatching cycles.\n- For one non-mutating suggested action, clear free-form acceptance such as \u0060yes\u0060, \u0060start\u0060, \u0060do it\u0060, or \u0060run <capability>\u0060 confirms that suggestion. Ambiguous replies get one clarifying question.\n\nUnclear mapping? Ask **one** clarifying question. Compound questions MUST NOT occur.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER execute implementation work. Status orients and routes; it MUST NOT build, audit, plan, or decide.\n- NEVER dump full artifact contents verbatim. Summarize concisely; the user can read the files themselves.\n- NEVER skip the briefing in returning mode. The user needs context before choosing a direction.\n- NEVER assume what the user wants without asking. Present the suggestion, then wait for confirmation.\n- NEVER modify any state artifact. Status is strictly read-only.\n- NEVER route to a capability without the user's consent. Suggest, don't force.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⌂ status · <status>\u0060 on its own line below the dashboard's closing code fence, followed by a one-sentence summary of what was delivered. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a \u0060▸\u0060 (VT15) bullet below the summary identifying what the user needs to decide or act on next. The exit marker MUST appear on every invocation regardless of mode and uses status's canonical glyph \u0060⌂\u0060 (SG1, U+2302).\n\n- **complete** (EX1): Briefing delivered (or welcome shown in fresh mode) and user successfully routed to a capability.\n- **flagged** (EX2): Briefing delivered but critical attention items were found: critical issues, degrading health, loop stop-condition triggers. Each concern MUST be listed explicitly.\n- **stuck** (EX3): Cannot orient: the working directory is not a code project, no readable files exist, or permissions prevent scanning.\n- **waiting** (EX4): Briefing or welcome delivered, suggestion made, awaiting user input on which direction to take.\n\n---\n\n## Cross-capability integration\n\nStatus is the suite entry point. It reads other capabilities' artifacts, produces no artifact, and outputs only a briefing plus routing suggestion.\n"`);
+export const instructions = JSON.parse(String.raw `"# STATUS\n\n**Holistic Entry Junction. Orient, Route, Activate**\n\nSingle entry point to the agentera suite. Detects fresh vs returning, delivers a situational briefing, routes to the right capability. Same path on first install and the 100th session.\n\nGlyph: **⌂** (SG1). Status reads suite state through \u0060agentera prime\u0060 and writes nothing. A bare user message of exactly \u0060/agentera\u0060 invokes this capability; it does not fall back to conversational smalltalk.\n\nStatus MUST source both instructions and bounded state from \u0060agentera prime --context status --format json\u0060 and write nothing. Read \u0060capability_context.instructions\u0060 in full, render from \u0060capability_context.context.status_context\u0060, and use the one \u0060capability_context.startup\u0060 aggregation. Its outcome is \u0060ok\u0060, \u0060degraded\u0060, or \u0060blocked\u0060; \u0060status_context.outcome\u0060 is the same value. For deferred detail, run only that availability row\u0027s exact \u0060detail_command\u0060. An \u0060ok\u0060 startup needs no second prime call. Status MUST NOT raw-read \u0060.agentera/*.yaml\u0060.\n\n---\n\n## Dashboard rendering\n\nStatus owns the prime dashboard contract. SKILL.md and other surfaces delegate here.\n\n\u0060\u0060\u0060text\n┌─┐┌─┐┌─┐┌┐┌┌─┐┌─┐┬─┐┌─┐\n├─┤│ ┬├┤ │││ │ ├┤ ├┬┘├─┤\n┴ ┴└─┘└─┘┘└┘ ┴ └─┘┴└─┴ ┴\n\n─── status ─────────────────────────────\n\n  ⛶ health    [⮉|⮋] [grade] ([worst dimension: grade])\n  ⇶ todo      N critical · M degraded · J annoying\n  ≡ plan      [██████▓░░░] N/M tasks\n  ⎘ optim     [metric] [current] → [target]\n  ♾ profile   [loaded | not found]\n\n  [1-2 sentence narrative read: what shipped, what's moving, what needs eyes.\n  Interpretation, not metrics. Closes the status section before attention.]\n\n─── attention ──────────────────────────\n\n  ⇶ [critical items, triple arrow for critical]\n  ⇉ [degraded items, double arrow for degraded]\n  → [normal items, single arrow for normal]\n  ⇢ [annoying items, dashed arrow for annoying]\n\n─── next ───────────────────────────────\n\n  suggested → [glyph] [capability] ([reason])\n\u0060\u0060\u0060\n\nBuild the dashboard from \u0060agentera prime --format json\u0060 output. Source labels such as \u0060mode:\u0060, \u0060profile:\u0060, \u0060v1_migration:\u0060, \u0060health:\u0060, \u0060todo:\u0060, \u0060plan:\u0060, \u0060objective:\u0060, \u0060attention:\u0060, \u0060next_action:\u0060, and the \u0060app.status\u0060 installed-app status object are parsing aids, not dashboard lines. Do not relay raw CLI lines as the user-facing briefing.\n\n**Output constraint**: ≤120 words total briefing, ≤15 words per routing suggestion.\n\n**Exit marker**: after the closing code fence of the dashboard, emit \u0060⌂ status · <status>\u0060 on its own line, followed by a one-sentence summary of what you delivered. For \u0060waiting\u0060, \u0060flagged\u0060, or \u0060stuck\u0060, add a \u0060▸\u0060 bullet below the summary identifying what the user needs to decide or act on next. The exit marker MUST appear on every invocation regardless of mode (fresh welcome or returning briefing).\n\n**Formatting rules**:\n- Each status line uses the skill glyph that owns that data\n- Severity arrows (VT5-VT8) mark attention items by urgency\n- Trend arrows (VT12/VT13) show health trajectory; derive ⮉/⮋ from \u0060health.degrading\u0060 (false→⮉, true→⮋); omit when no audit history\n- Progress bars (VT18) show plan completion visually\n- The inline separator (VT16) joins counts on a single line\n- Lead with status metrics, then the narrative read inside the status section\n- The narrative read is colleague interpretation; metric lines above it are evidence\n- The todo summary line lists critical, degraded, and annoying counts only; normal-priority items belong in attention with → (SI3), not on the summary line\n- Omit any line whose source artifact is missing\n- Omit any section that would be empty (e.g., no attention items = no attention section)\n\nVisual token IDs live in \u0060skills/agentera/protocol.yaml\u0060; see VT, SI, EX, SG, PH families.\n\n---\n\n## Briefing\n\nUse the \u0060mode\u0060 field from \u0060agentera prime\u0060 to detect fresh vs returning:\n\n- **Fresh** (\u0060mode: fresh\u0060): render welcome language; lead with the suggested capability from \u0060next_action\u0060. Do not enumerate the full suite unless asked.\n- **Returning** (\u0060mode: returning\u0060): render the dashboard template above using \u0060mode\u0060, \u0060profile\u0060, \u0060health\u0060, \u0060todo\u0060, \u0060plan\u0060, \u0060objective\u0060, \u0060attention\u0060, and \u0060next_action\u0060 fields.\n\nNarration voice: warm, brief, unscripted.\n\n### Project integration rendering\n\nWhen \u0060project_integration.recommendation\u0060 is \u0060upgrade\u0060:\n1. Render the plain-language \u0060project_integration.message\u0060.\n2. Show \u0060project_integration.dry_run_command\u0060 preview; state that it changes nothing.\n3. Ask before running \u0060project_integration.apply_command\u0060.\n\nWhen \u0060recommendation\u0060 is \u0060stay\u0060, do not suggest upgrade.\n\n### App status rendering\n\nRender \u0060app.status\u0060 as a status line only when it is not \u0060up_to_date\u0060. Use the plain-language \u0060project_integration.message\u0060 if present. Status MUST NOT teach install-recovery procedure — that belongs to the upgrade capability and \u0060agentera doctor\u0060.\n\n### Profile rendering\n\nRender \u0060profile.status\u0060 (\u0060loaded\u0060 or \u0060not found\u0060). Render \u0060profile.suggested_action\u0060 or a missing-profile attention item only when prime supplies one.\n\n### Attention items\n\nPriority order with severity arrows (SI1-SI4):\n\n- ⇶ (SI1) Critical issues, degrading health dimensions\n- ⇉ (SI2) Blocked/overdue plan tasks, stale artifacts, overdue health audits (prime \u0060health.stale=true\u0060), loop stop-condition triggers\n- → (SI3) Standard work: features, improvements, routine tasks\n- ⇢ (SI4) Unresolved exploratory decisions\n\nA clean bill of health is useful — say so when nothing is flagged.\n\n---\n\n## Routing suggestion\n\nThe routing suggestion MUST name the artifact item it would act on. A skill name without a concrete object is not a valid suggestion.\n\nValid objects: \u0060PLAN Task N: <title>\u0060, \u0060TODO: <item>\u0060, \u0060DECISION N follow-up\u0060, \u0060OBJECTIVE: <metric>\u0060, or \u0060VISION refresh\u0060.\n\n**Priority order** (SG codes are internal protocol references; never render them in user-facing handoff labels):\n\n- Active PLAN with pending tasks → suggest ⎈ orchestrate for the first unblocked pending task.\n- Critical or degrading health → suggest ⛶ audit or ⧉ build for the named finding.\n- Stale health audit (CLI \u0060health.stale=true\u0060) with no higher-priority work → suggest ⛶ audit for \u0060HEALTH: Audit N stale\u0060.\n- Active non-closed OBJECTIVE with stalled or missing metric evidence → suggest ⎘ optimize for that metric.\n- todo open items → select the highest-severity open item, then route by shape: narrow one-cycle todo items suggest ⧉ build; contract-shaped, multi-surface, dependency-heavy, migration, schema, metadata, validation, or acceptance-risky todo items suggest ≡ plan first. Prefer items that unlock product evidence or future plans.\n- Pending decisions follow-up → suggest ❈ discuss for the named unresolved decision.\n- Vision exists but no plan, objective, decision follow-up, or TODO work is active → suggest ≡ plan.\n- No vision, no executable follow-ups, and no active plan → suggest ⛥ vision to choose a direction.\n\nDo not let \u0060healthy + plan complete → ⛥\u0060 override active TODO, OBJECTIVE, DECISIONS, or a newer active PLAN. A completed plan means \"look for the next executable follow-up,\" not automatically \"refresh vision.\"\n\n### Routing posture\n\n- Present one concrete suggestion and let the user choose. Coercion MUST NOT occur.\n- Do not list generic skill options unless the user asks for the full menu.\n- The waiting bullet should ask whether to run the named action, not ask the user to pick from skills.\n- On the initial status brief, use a free-form continuation prompt rather than a native question menu unless the user asked for bounded choices or the suggested next step is a state-changing Proceed/Cancel handoff.\n- Mid-conversation, use the native question tool only for at least two meaningful non-terminal next actions or a consequential Proceed/Cancel decision; \u0060Done\u0060 and free-form/custom answer affordances do not count as alternatives.\n- State-changing handoffs are consequential Proceed/Cancel decisions even when there is only one suggested action. State-changing means the proposed next step may write artifacts, edit code, run optimization or orchestration cycles, apply migrations, refresh app/runtime state, or otherwise mutate project/runtime state.\n- Use the behavior rule first, with common examples such as ⧉ build, ≡ plan when creating or updating plans, ▤ document when writing docs, ⎘ optimize when running or applying optimization cycles, and ⎈ orchestrate when dispatching cycles.\n- For one non-mutating suggested action, clear free-form acceptance such as \u0060yes\u0060, \u0060start\u0060, \u0060do it\u0060, or \u0060run <capability>\u0060 confirms that suggestion. Ambiguous replies get one clarifying question.\n\nUnclear mapping? Ask **one** clarifying question. Compound questions MUST NOT occur.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER execute implementation work. Status orients and routes; it MUST NOT build, audit, plan, or decide.\n- NEVER dump full artifact contents verbatim. Summarize concisely; the user can read the files themselves.\n- NEVER skip the briefing in returning mode. The user needs context before choosing a direction.\n- NEVER assume what the user wants without asking. Present the suggestion, then wait for confirmation.\n- NEVER modify any state artifact. Status is strictly read-only.\n- NEVER route to a capability without the user's consent. Suggest, don't force.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⌂ status · <status>\u0060 on its own line below the dashboard's closing code fence, followed by a one-sentence summary of what was delivered. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a \u0060▸\u0060 (VT15) bullet below the summary identifying what the user needs to decide or act on next. The exit marker MUST appear on every invocation regardless of mode and uses status's canonical glyph \u0060⌂\u0060 (SG1, U+2302).\n\n- **complete** (EX1): Briefing delivered (or welcome shown in fresh mode) and user successfully routed to a capability.\n- **flagged** (EX2): Briefing delivered but critical attention items were found: critical issues, degrading health, loop stop-condition triggers. Each concern MUST be listed explicitly.\n- **stuck** (EX3): Cannot orient: the working directory is not a code project, no readable files exist, or permissions prevent scanning.\n- **waiting** (EX4): Briefing or welcome delivered, suggestion made, awaiting user input on which direction to take.\n\n---\n\n## Cross-capability integration\n\nStatus is the suite entry point. It reads other capabilities' artifacts, produces no artifact, and outputs only a briefing plus routing suggestion.\n"`);
 export default `${instructions
     .replaceAll("loaded | not found", "valid | absent | repair_needed")
     .replaceAll("loaded or not found", "valid, absent, or repair_needed")
@@ -9,4 +9,3 @@ export default `${instructions
 ### Profile validity
 
 Render the shared profile validity exactly as \`valid\`, \`absent\`, or \`repair_needed\`. Freshness is separate and may be \`current\`, \`stale\`, or \`unknown\`; only valid stale input may carry stale guidance. Repair-needed input preserves its repair recovery and MUST NOT receive refresh advice. Never render profile path or content.`;
-//# sourceMappingURL=instructions.js.map

package/dist/capabilities/status/startupInstructions.js

@@ -10,10 +10,6 @@ export function statusStartupInstructions(canonical) {
             "Glyph: **⌂** (SG1). Status reads suite state through `agentera prime` and writes nothing.",
             "Glyph: **⌂** (SG1). Status reads its startup capsule through `agentera prime --context status --format json` and writes nothing.",
         ],
-        [
-            "Status MUST source state from `agentera prime --format json` and write nothing. The `source_contract.capability_startup` field declares whether prime is complete for capability startup; when complete, status MUST NOT run separate artifact queries or raw `.agentera/*.yaml` reads. If prime fails or reports incomplete state, fall back to commands listed in `source_contract.cli_fallback` as a last resort.",
-            "Status MUST source both instructions and bounded state from `agentera prime --context status --format json` and write nothing. Read `capability_context.instructions` in full and render from `capability_context.context.status_context`; its `source_contract.capability_startup` field declares whether the included state is complete for capability startup. Status MUST NOT run a separate bare-prime call or raw `.agentera/*.yaml` read. If the status capsule fails or reports incomplete state, use commands listed in `capability_context.state.fallback_commands` as a last resort, then name the omitted detail and its authoritative recovery command.",
-        ],
         [
             "Build the dashboard from `agentera prime --format json` output.",
             "Build the dashboard from `capability_context.context.status_context` in the status startup response.",
@@ -36,4 +32,3 @@ export function statusStartupInstructions(canonical) {
     }
     return adapted;
 }
-//# sourceMappingURL=startupInstructions.js.map

package/dist/capabilities/vision/instructions.js

@@ -1,5 +1,4 @@
 // Capability instructions for vision (canonical per D57; D65 relocated from .md to .ts)
 // Served via `agentera prime --context vision --format json`. RFC 2119 modal vocab per D71.
-export const instructions = JSON.parse(String.raw `"# VISION\n\n**Strategic Layer. Envision, Refine, Anchor**\n\nThe strategic steward of the canonical vision artifact, stored as \u0060.agentera/vision.yaml\u0060 unless mapped otherwise. Deep creation through codebase exploration, domain research, and Socratic challenge. Ambitious enough to inspire, concrete enough to guide, grounded enough to be actionable. Glyph: **⛥** (protocol ref: SG6), used in the mandatory exit marker.\n\nTwo modes: **create** (new projects) and **refine** (evolve existing visions).\n\nVision MUST source state from \u0060agentera prime --context vision --format json\u0060 and write only the vision artifact, archived-vision history under \u0060.agentera/archive/\u0060, and \u0060.agentera/docs.yaml\u0060 artifact-mapping updates if a new path override is required. The \u0060source_contract.capability_startup\u0060 field declares \u0060complete_for_capability_startup\u0060; when complete, vision MUST NOT run separate artifact CLI calls or raw \u0060.agentera/*.yaml\u0060 reads for state prime already serves. If prime fails or reports incomplete state for a needed family, run the \u0060cli_fallback\u0060 commands listed in \u0060source_contract.capability_startup\u0060 as a last resort.\n\n---\n\n## State artifacts\n\nOne agent-facing file in \u0060.agentera/\u0060 by default, plus a per-project archive directory.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060vision\u0060 | Canonical vision artifact. North star, direction, principles, personas, aspirations, identity, tension. An evergreen constitution. | Created via deep brainstorm session, written to \u0060.agentera/vision.yaml\u0060 by default. |\n| \u0060.agentera/archive/\u0060 | Completed Replace-mode predecessors, retained as corrective context. | Created on first Replace-mode archive; files named \u0060vision-{date}.yaml\u0060. |\n\nRead-needs (sourced via \u0060vision_startup_context\u0060 when complete): vision, decisions, progress, health, todo, design, docs, profile. Write-targets: vision only.\n\nUse \u0060agentera schema --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060vision\u0060 to locate the active installed schema; do not search Agentera directories manually. Existing vision artifacts provide repository-local examples of the shape. Vision adapts and expands them based on the conversation.\n\n### vision.yaml shape\n\n\u0060\u0060\u0060yaml\nproject_name: Project Name\nnorth_star: The dream. Not what the software does, but what it makes possible.\npersonas:\n  - name: Persona name\n    description: Their day, frustrations, and workflow.\nprinciples:\n  - name: Principle name\n    description: What this principle optimizes for and what it resists.\ndirection: Where this project is heading. Aspirational, not prescriptive.\nidentity:\n  personality: adjective · adjective · adjective\n  voice: How it communicates.\n  emotional_register: What it feels like to use.\n  naming: Convention or philosophy.\ntension: The hardest tension in the vision.\n\u0060\u0060\u0060\n\nEach principle MUST state a tradeoff direction (\"A over B when they conflict\"). Principles SHOULD name what each one actively prevents. Principles MUST NOT name specific libraries, modules, file paths, or implementation patterns — those belong in constraints or task scope. \"Tests over time-to-first-commit\" is a principle; \"use vitest\" is not.\n\nVision MUST be ambitious enough for months of development, personas concrete enough for \"who is this for?\" debates, direction clear enough to derive next steps, and identity vivid enough to guide decisions from error messages to module names. If DESIGN.md exists, the \u0060identity\u0060 section SHOULD cohere with the visual system declared there.\n\n---\n\n## Workflow phases (mode-split: Step 0 detect, then Create 1-5 or Refine 1-5; emit \u0060── step N/5: verb\u0060 before each step — verbs listed per mode below)\n\n### Step 0: Detect mode\n\nRun \u0060agentera state query vision --format json\u0060. If \u0060source.exists=false\u0060, proceed to **Create** mode. If \u0060source.exists=true\u0060, present the mode choice:\n\n> **Refine**: Evolve the existing vision based on what you've learned. Reads the current vision, the codebase state, and recent progress to propose informed updates.\n>\n> **Replace**: Start fresh with a deep brainstorm. Archives the current vision and creates a new one from scratch.\n\nIf **Refine**, skip to Refine mode. If **Replace**, archive the current vision artifact to \u0060.agentera/archive/vision-{date}.yaml\u0060, then proceed to Create mode (which will read the archive as corrective context in Step 1).\n\n### Pre-write self-audit (shared by Create Step 4 and Refine Step 4)\n\nBefore writing the vision artifact, run \u0060agentera check lint --artifact vision --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (≥1 concrete anchor per principle), and filler accumulation (banned patterns). Max 3 revision attempts. Flag with \u0060[post-audit-flagged]\u0060 if still failing after 3 attempts.\n\n---\n\n### Create mode\n\nSteps: explore, research, converse, audit, write.\n\n#### Step 1: Explore the codebase\n\nIf code exists, read deeply before asking questions. You arrive informed.\n\n1. Source state from \u0060agentera prime --context vision --format json\u0060's \u0060vision_startup_context\u0060 body — progress (latest cycle), health (grade + trajectory), todo (open counts by severity), profile (path; if \u0060stale=true\u0060, carry the caveat forward; do NOT invoke profile to refresh state during a vision cycle — prime covers only reading).\n2. For \u0060decisions\u0060 (status \u0060fallback_only\u0060 or unavailable): run \u0060agentera state decisions list --limit 20 --format json\u0060; preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure rather than raw-reading historical decision context.\n3. For \u0060vision\u0060 itself when in Replace mode: read \u0060.agentera/archive/vision-{date}.yaml\u0060 (the artifact just archived in Step 0) for context on what to avoid.\n4. Map project structure: directory layout, key modules, entry points.\n5. Read dependency manifests: stack, libraries, what choices reveal.\n6. Read \u0060README.md\u0060 and \u0060AGENTS.md\u0060 (v3 canonical project guidance) if they exist.\n7. Read key source files to understand what the software does today.\n8. Read \u0060DESIGN.md\u0060 (project root) if it exists, for existing visual identity. The \u0060design\u0060 artifact family is \u0060fallback_only\u0060 in prime; this filesystem read at project root is the canonical read path.\n9. \u0060git log --oneline -30\u0060 for the recent story.\n\nSynthesize: \"The project does X, built with Y, moving toward Z. Strongest patterns: A. Gaps: B.\"\n\nGreenfield (no code exists)? Skip to Step 2.\n\n#### Step 2: Research the domain\n\nSearch for context grounding the vision in reality:\n\n1. **What exists**: similar tools, competing approaches, adjacent projects\n2. **State of the art**: recent developments, emerging patterns\n3. **What's missing**: suite gaps this project could fill\n4. **Who talks about it**: communities, forums, common frustrations\n\n3-5 targeted searches. Synthesize: \"The gap is X. The opportunity is Y.\"\n\n#### Step 3: The conversation\n\nEngage the user. Ask one question at a time through the native question tool (always include a \u0060Done\u0060 option). Adopt the conversational voice defined in the project's vision artifact \u0060identity.voice\u0060 field when available — do not improvise a separate personality. In Create mode before a vision exists, run with a neutral operational stance; personality emerges from arc 5 below and is captured in the artifact.\n\nOperational stance: Socratic. Push past safe answers. Vision's job is to surface an inarticulate dream through challenge, not interview the user through a checklist.\n\nFollow a narrative arc, not a checklist. Adapt, but cover:\n\n1. **The dream**: \"Based on what I see in the codebase [and the domain research], here's where I think this wants to go: [synthesis]. But I bet you're thinking bigger than that. What does this project make possible if it wildly succeeds?\" Push beyond utility: \"It does X faster, but why does that matter? What can they do that they couldn't before?\"\n\n2. **The people**: \"Who reaches for this? Not 'developers,' a specific person. Their Tuesday morning. The frustration that makes them think 'I need something better'?\" Challenge abstract personas: \"'Data engineers': the one at a startup with 3 services, or the one at a bank with 3,000?\"\n\n3. **The principles**: \"What principles should guide every decision? What do you optimize for when you can't have everything? What do you actively resist?\" If decision profile exists, propose principles from it: \"Your profile says you value X over Y. Should that be a principle here?\"\n\n4. **The direction**: \"Given all of that, where is this heading? Not features. Capabilities. What kind of tool does this become in a year? What would surprise you?\" Also ask what it should NOT become: \"In five years you give up and move to a competitor — what killed it? Name that trait and exclude it here.\" Fold the answer into \u0060direction\u0060 as a scope boundary.\n\n5. **The identity**: \"If this product were a person, bold and direct, or quiet and precise? How does it talk? How should it feel to use? What emotion does a successful interaction leave?\" Also naming: \"Convention, cultural reference, philosophy?\" If DESIGN.md exists: \"Your visual system says X. Does the verbal identity match?\"\n\n6. **The tension**: \"What's the hardest tension in this vision? Where do the principles conflict? What will you have to give up to get what matters most?\"\n\n#### Step 4: Pre-write self-audit\n\nExercise the shared pre-write self-audit rule (declared above under Workflow phases).\n\n#### Step 5: Write the vision artifact\n\nSynthesize into an aspirational north star. **Tone**: evocative, not clinical. A rallying cry, not a requirements doc. **Structure**: follow template but adapt; add dimensions that emerged, omit sections that produced nothing interesting.\n\nPresent the draft to the user.\n\n\n---\n\n### Refine mode\n\nSteps: read, research, propose, audit, update.\n\n#### Step 1: Read the current state\n\n1. Run \u0060agentera state query vision --format json\u0060 for the current vision artifact's content and \u0060source.path\u0060.\n2. Source state from \u0060agentera prime --context vision --format json\u0060's \u0060vision_startup_context\u0060 body — progress, health, todo, profile (with same stale-case handling as Create Step 1).\n3. For decisions (status \u0060fallback_only\u0060): run \u0060agentera state decisions list --limit 20 --format json\u0060; carry \u0060compacted\u0060 / \u0060missing_fields\u0060 / \u0060caveats\u0060 / \u0060satisfaction.review_needed\u0060 pressure forward rather than reconstructing absent historical context.\n4. Read the codebase (same depth as Create Step 1 — rows 4–9: structure, manifests, README/AGENTS, source files, DESIGN.md if present, git log).\n5. Review the todo slice for recurring problems that suggest the vision needs adjustment.\n\n#### Step 2: Research updates\n\nSearch for domain developments since the vision was written: new tools, community shifts, things the user might not have seen.\n\n#### Step 3: Propose changes\n\nPresent your assessment:\n\n> Here's what's changed since the vision was written:\n>\n> - The project has built [A, B, C] (from progress state)\n> - Decision [X] shifted thinking about [Y] (from decisions state)\n> - The domain has moved: [Z] (from research)\n> - Recurring TODO items suggest: [W] (from todo state)\n>\n> I'd suggest updating:\n>\n> - [Section]: [what to change and why]\n>\n> What resonates? What's off?\n\nBrief conversation (2–4 exchanges) to refine proposed changes.\n\n#### Step 4: Pre-write self-audit\n\nExercise the shared pre-write self-audit rule (declared above under Workflow phases).\n\n#### Step 5: Update the vision artifact\n\nShow the updated vision as a diff (what changed and why).\n\n---\n\n## Safety rails\n\n<critical>\n- MUST NOT write the vision artifact without explicit user approval. Present drafts and get confirmation.\n- MUST NOT modify the vision artifact during a build cycle; changes belong in dedicated vision sessions.\n- MUST NOT produce a clinical, requirements-style document. The vision SHOULD inspire, not specify. If it reads like a PRD, rewrite it.\n- MUST NOT skip the codebase exploration (Step 1) when code exists.\n- MUST NOT propose a vision so vague it cannot guide autonomous development. \"Make a great tool\" is not a vision. \"Make it possible for a solo developer to ship production-grade systems by letting an AI team handle the parts they'd otherwise skip\" is.\n- MUST NOT dismiss the user's ambition. If they dream big, help them articulate it. If they think small, push them bigger. Never cap aspiration.\n- MUST NOT invoke profile to refresh PROFILE.md during a vision cycle. Profile state is read-only context for vision; refreshing mutates state outside vision's contract.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⛥ vision · <status>\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a \u0060▸\u0060 (VT15) bullet below the summary identifying what needs resolution. The exit marker is mandatory on every invocation.\n\n- **complete** (EX1): The vision artifact was written (Create/Replace mode) or updated (Refine mode) with explicit user approval; the vision is ambitious, concrete, and structured to sustain autonomous development.\n- **flagged** (EX2): The vision was produced but with weaknesses worth surfacing: the user settled for a less ambitious or less specific vision than the capability pushed for, key sections (personas, principles, direction) are thin due to limited conversation depth, or the vision has unresolved tensions with existing decision entries.\n- **stuck** (EX3): Cannot write the vision artifact because the user declined to approve the draft and no actionable revision direction was given, or codebase exploration failed in a way that would make the vision unreliable (e.g., inaccessible repo).\n- **waiting** (EX4): The user has not provided enough about the project's purpose or direction to write a meaningful vision, and the codebase (if any) does not provide sufficient signal to proceed without a conversation.\n\n---\n\n## Cross-capability integration\n\nVision is the strategic layer — the capability that defines where the project is going within the twelve-capability suite.\n\n### Vision produces what build consumes\n\nThe vision artifact drives build's work selection every cycle. When vision is installed, build defers to it; otherwise build runs its own quick brainstorm. Both produce the same \u0060.agentera/vision.yaml\u0060 shape — the capabilities are interchangeable at the artifact level.\n\n### Vision is informed by discuss\n\nDecision entries provide context for vision refinement: what choices have been made and why. When vision detects that decisions have shifted thinking away from the current vision, it surfaces this during refine mode.\n\n### Vision is informed by profile\n\nThe decision profile calibrates the vision conversation: what patterns the user values, what principles they've established across projects, what they resist. High-confidence entries (CS1-CS2, 70+) become proposed principles in the vision.\n\n### Vision is informed by research\n\nResearch that shifts the project's direction lands in the decisions artifact; vision picks up the captured insight during refine mode.\n\n### Vision is informed by audit\n\nThe health artifact tells vision what structural realities constrain the vision. A project with D-grade architecture may need a vision adjustment, or the vision may confirm that the architecture needs to change.\n\n### Vision reads design output\n\nVision reads DESIGN.md (in Create Step 1) for the project's visual identity. The \u0060identity\u0060 section SHOULD cohere with this visual system. Vision never writes DESIGN.md; design owns all writes.\n\n### Vision reads document output\n\nDOCS.md provides artifact path resolution for the canonical vision artifact and signals what documentation exists in the project.\n\n### Vision feeds plan\n\nWhen a new or refined vision changes the project's direction, plan can produce a plan to realign the codebase with the updated vision.\n\n### Invocation guidance (consumer perspective)\n\n**New project**: invoke ⛥ vision for deep creation of the vision artifact through codebase exploration, domain research, and aspirational conversation. Then ≡ plan to plan the first features (if complex), then ⧉ build to start building.\n\n**Existing project without a vision**: invoke ⛥ vision to read the codebase, understand what exists, then push the user to articulate where it should go.\n\n**Vision refinement**: invoke ⛥ vision to detect the existing vision artifact, offer refine mode, read progress and decisions since last update, propose informed changes.\n\n**Without vision installed**: build's built-in quick brainstorm creates a workable vision artifact. Vision adds depth and stewardship but is not required for the suite to function.\n"`);
+export const instructions = JSON.parse(String.raw `"# VISION\n\n**Strategic Layer. Envision, Refine, Anchor**\n\nThe strategic steward of the canonical vision artifact, stored as \u0060.agentera/vision.yaml\u0060 unless mapped otherwise. Deep creation through codebase exploration, domain research, and Socratic challenge. Ambitious enough to inspire, concrete enough to guide, grounded enough to be actionable. Glyph: **⛥** (protocol ref: SG6), used in the mandatory exit marker.\n\nTwo modes: **create** (new projects) and **refine** (evolve existing visions).\n\nVision MUST source state from \u0060agentera prime --context vision --format json\u0060 and write only the vision artifact, archived-vision history under \u0060.agentera/archive/\u0060, and \u0060.agentera/docs.yaml\u0060 artifact-mapping updates if a new path override is required. Read \u0060capability_context.startup\u0060. Observe \u0060outcome\u0060; use bounded context already served for an \u0060included\u0060 availability row, and run a \u0060deferred\u0060 row\u0027s exact \u0060detail_command\u0060 before any raw artifact diagnostic. If startup is \u0060blocked\u0060, use \u0060detail_discovery.schema\u0060 to inspect recovery; do not raw-read \u0060.agentera/*.yaml\u0060.\n\n---\n\n## State artifacts\n\nOne agent-facing file in \u0060.agentera/\u0060 by default, plus a per-project archive directory.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060vision\u0060 | Canonical vision artifact. North star, direction, principles, personas, aspirations, identity, tension. An evergreen constitution. | Created via deep brainstorm session, written to \u0060.agentera/vision.yaml\u0060 by default. |\n| \u0060.agentera/archive/\u0060 | Completed Replace-mode predecessors, retained as corrective context. | Created on first Replace-mode archive; files named \u0060vision-{date}.yaml\u0060. |\n\nRead-needs (sourced via \u0060vision_startup_context\u0060 when complete): vision, decisions, progress, health, todo, design, docs, profile. Write-targets: vision only.\n\nUse \u0060agentera schema --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060vision\u0060 to locate the active installed schema; do not search Agentera directories manually. Existing vision artifacts provide repository-local examples of the shape. Vision adapts and expands them based on the conversation.\n\n### vision.yaml shape\n\n\u0060\u0060\u0060yaml\nproject_name: Project Name\nnorth_star: The dream. Not what the software does, but what it makes possible.\npersonas:\n  - name: Persona name\n    description: Their day, frustrations, and workflow.\nprinciples:\n  - name: Principle name\n    description: What this principle optimizes for and what it resists.\ndirection: Where this project is heading. Aspirational, not prescriptive.\nidentity:\n  personality: adjective · adjective · adjective\n  voice: How it communicates.\n  emotional_register: What it feels like to use.\n  naming: Convention or philosophy.\ntension: The hardest tension in the vision.\n\u0060\u0060\u0060\n\nEach principle MUST state a tradeoff direction (\"A over B when they conflict\"). Principles SHOULD name what each one actively prevents. Principles MUST NOT name specific libraries, modules, file paths, or implementation patterns — those belong in constraints or task scope. \"Tests over time-to-first-commit\" is a principle; \"use vitest\" is not.\n\nVision MUST be ambitious enough for months of development, personas concrete enough for \"who is this for?\" debates, direction clear enough to derive next steps, and identity vivid enough to guide decisions from error messages to module names. If DESIGN.md exists, the \u0060identity\u0060 section SHOULD cohere with the visual system declared there.\n\n---\n\n## Workflow phases (mode-split: Step 0 detect, then Create 1-5 or Refine 1-5; emit \u0060── step N/5: verb\u0060 before each step — verbs listed per mode below)\n\n### Step 0: Detect mode\n\nRun \u0060agentera state query vision --format json\u0060. If \u0060source.exists=false\u0060, proceed to **Create** mode. If \u0060source.exists=true\u0060, present the mode choice:\n\n> **Refine**: Evolve the existing vision based on what you've learned. Reads the current vision, the codebase state, and recent progress to propose informed updates.\n>\n> **Replace**: Start fresh with a deep brainstorm. Archives the current vision and creates a new one from scratch.\n\nIf **Refine**, skip to Refine mode. If **Replace**, archive the current vision artifact to \u0060.agentera/archive/vision-{date}.yaml\u0060, then proceed to Create mode (which will read the archive as corrective context in Step 1).\n\n### Pre-write self-audit (shared by Create Step 4 and Refine Step 4)\n\nBefore writing the vision artifact, run \u0060agentera check lint --artifact vision --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (≥1 concrete anchor per principle), and filler accumulation (banned patterns). Max 3 revision attempts. Flag with \u0060[post-audit-flagged]\u0060 if still failing after 3 attempts.\n\n---\n\n### Create mode\n\nSteps: explore, research, converse, audit, write.\n\n#### Step 1: Explore the codebase\n\nIf code exists, read deeply before asking questions. You arrive informed.\n\n1. Source state from \u0060agentera prime --context vision --format json\u0060's \u0060vision_startup_context\u0060 body — progress (latest cycle), health (grade + trajectory), todo (open counts by severity), profile (path; if \u0060stale=true\u0060, carry the caveat forward; do NOT invoke profile to refresh state during a vision cycle — prime covers only reading).\n2. For \u0060decisions\u0060: when its \u0060capability_context.startup.availability\u0060 row is \u0060deferred\u0060, run that row\u0027s exact \u0060detail_command\u0060; preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure rather than raw-reading historical decision context.\n3. For \u0060vision\u0060 itself when in Replace mode: read \u0060.agentera/archive/vision-{date}.yaml\u0060 (the artifact just archived in Step 0) for context on what to avoid.\n4. Map project structure: directory layout, key modules, entry points.\n5. Read dependency manifests: stack, libraries, what choices reveal.\n6. Read \u0060README.md\u0060 and \u0060AGENTS.md\u0060 (v3 canonical project guidance) if they exist.\n7. Read key source files to understand what the software does today.\n8. Read \u0060DESIGN.md\u0060 (project root) if it exists, for existing visual identity. The \u0060design\u0060 artifact family is \u0060deferred\u0060 in \u0060capability_context.startup.availability\u0060; use its exact \u0060detail_command\u0060 before a filesystem diagnostic.\n9. \u0060git log --oneline -30\u0060 for the recent story.\n\nSynthesize: \"The project does X, built with Y, moving toward Z. Strongest patterns: A. Gaps: B.\"\n\nGreenfield (no code exists)? Skip to Step 2.\n\n#### Step 2: Research the domain\n\nSearch for context grounding the vision in reality:\n\n1. **What exists**: similar tools, competing approaches, adjacent projects\n2. **State of the art**: recent developments, emerging patterns\n3. **What's missing**: suite gaps this project could fill\n4. **Who talks about it**: communities, forums, common frustrations\n\n3-5 targeted searches. Synthesize: \"The gap is X. The opportunity is Y.\"\n\n#### Step 3: The conversation\n\nEngage the user. Ask one question at a time through the native question tool (always include a \u0060Done\u0060 option). Adopt the conversational voice defined in the project's vision artifact \u0060identity.voice\u0060 field when available — do not improvise a separate personality. In Create mode before a vision exists, run with a neutral operational stance; personality emerges from arc 5 below and is captured in the artifact.\n\nOperational stance: Socratic. Push past safe answers. Vision's job is to surface an inarticulate dream through challenge, not interview the user through a checklist.\n\nFollow a narrative arc, not a checklist. Adapt, but cover:\n\n1. **The dream**: \"Based on what I see in the codebase [and the domain research], here's where I think this wants to go: [synthesis]. But I bet you're thinking bigger than that. What does this project make possible if it wildly succeeds?\" Push beyond utility: \"It does X faster, but why does that matter? What can they do that they couldn't before?\"\n\n2. **The people**: \"Who reaches for this? Not 'developers,' a specific person. Their Tuesday morning. The frustration that makes them think 'I need something better'?\" Challenge abstract personas: \"'Data engineers': the one at a startup with 3 services, or the one at a bank with 3,000?\"\n\n3. **The principles**: \"What principles should guide every decision? What do you optimize for when you can't have everything? What do you actively resist?\" If decision profile exists, propose principles from it: \"Your profile says you value X over Y. Should that be a principle here?\"\n\n4. **The direction**: \"Given all of that, where is this heading? Not features. Capabilities. What kind of tool does this become in a year? What would surprise you?\" Also ask what it should NOT become: \"In five years you give up and move to a competitor — what killed it? Name that trait and exclude it here.\" Fold the answer into \u0060direction\u0060 as a scope boundary.\n\n5. **The identity**: \"If this product were a person, bold and direct, or quiet and precise? How does it talk? How should it feel to use? What emotion does a successful interaction leave?\" Also naming: \"Convention, cultural reference, philosophy?\" If DESIGN.md exists: \"Your visual system says X. Does the verbal identity match?\"\n\n6. **The tension**: \"What's the hardest tension in this vision? Where do the principles conflict? What will you have to give up to get what matters most?\"\n\n#### Step 4: Pre-write self-audit\n\nExercise the shared pre-write self-audit rule (declared above under Workflow phases).\n\n#### Step 5: Write the vision artifact\n\nSynthesize into an aspirational north star. **Tone**: evocative, not clinical. A rallying cry, not a requirements doc. **Structure**: follow template but adapt; add dimensions that emerged, omit sections that produced nothing interesting.\n\nPresent the draft to the user.\n\n\n---\n\n### Refine mode\n\nSteps: read, research, propose, audit, update.\n\n#### Step 1: Read the current state\n\n1. Run \u0060agentera state query vision --format json\u0060 for the current vision artifact's content and \u0060source.path\u0060.\n2. Source state from \u0060agentera prime --context vision --format json\u0060's \u0060vision_startup_context\u0060 body — progress, health, todo, profile (with same stale-case handling as Create Step 1).\n3. For decisions: when its \u0060capability_context.startup.availability\u0060 row is \u0060deferred\u0060, run that row\u0027s exact \u0060detail_command\u0060; carry \u0060compacted\u0060 / \u0060missing_fields\u0060 / \u0060caveats\u0060 / \u0060satisfaction.review_needed\u0060 pressure forward rather than reconstructing absent historical context.\n4. Read the codebase (same depth as Create Step 1 — rows 4–9: structure, manifests, README/AGENTS, source files, DESIGN.md if present, git log).\n5. Review the todo slice for recurring problems that suggest the vision needs adjustment.\n\n#### Step 2: Research updates\n\nSearch for domain developments since the vision was written: new tools, community shifts, things the user might not have seen.\n\n#### Step 3: Propose changes\n\nPresent your assessment:\n\n> Here's what's changed since the vision was written:\n>\n> - The project has built [A, B, C] (from progress state)\n> - Decision [X] shifted thinking about [Y] (from decisions state)\n> - The domain has moved: [Z] (from research)\n> - Recurring TODO items suggest: [W] (from todo state)\n>\n> I'd suggest updating:\n>\n> - [Section]: [what to change and why]\n>\n> What resonates? What's off?\n\nBrief conversation (2–4 exchanges) to refine proposed changes.\n\n#### Step 4: Pre-write self-audit\n\nExercise the shared pre-write self-audit rule (declared above under Workflow phases).\n\n#### Step 5: Update the vision artifact\n\nShow the updated vision as a diff (what changed and why).\n\n---\n\n## Safety rails\n\n<critical>\n- MUST NOT write the vision artifact without explicit user approval. Present drafts and get confirmation.\n- MUST NOT modify the vision artifact during a build cycle; changes belong in dedicated vision sessions.\n- MUST NOT produce a clinical, requirements-style document. The vision SHOULD inspire, not specify. If it reads like a PRD, rewrite it.\n- MUST NOT skip the codebase exploration (Step 1) when code exists.\n- MUST NOT propose a vision so vague it cannot guide autonomous development. \"Make a great tool\" is not a vision. \"Make it possible for a solo developer to ship production-grade systems by letting an AI team handle the parts they'd otherwise skip\" is.\n- MUST NOT dismiss the user's ambition. If they dream big, help them articulate it. If they think small, push them bigger. Never cap aspiration.\n- MUST NOT invoke profile to refresh PROFILE.md during a vision cycle. Profile state is read-only context for vision; refreshing mutates state outside vision's contract.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⛥ vision · <status>\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a \u0060▸\u0060 (VT15) bullet below the summary identifying what needs resolution. The exit marker is mandatory on every invocation.\n\n- **complete** (EX1): The vision artifact was written (Create/Replace mode) or updated (Refine mode) with explicit user approval; the vision is ambitious, concrete, and structured to sustain autonomous development.\n- **flagged** (EX2): The vision was produced but with weaknesses worth surfacing: the user settled for a less ambitious or less specific vision than the capability pushed for, key sections (personas, principles, direction) are thin due to limited conversation depth, or the vision has unresolved tensions with existing decision entries.\n- **stuck** (EX3): Cannot write the vision artifact because the user declined to approve the draft and no actionable revision direction was given, or codebase exploration failed in a way that would make the vision unreliable (e.g., inaccessible repo).\n- **waiting** (EX4): The user has not provided enough about the project's purpose or direction to write a meaningful vision, and the codebase (if any) does not provide sufficient signal to proceed without a conversation.\n\n---\n\n## Cross-capability integration\n\nVision is the strategic layer — the capability that defines where the project is going within the twelve-capability suite.\n\n### Vision produces what build consumes\n\nThe vision artifact drives build's work selection every cycle. When vision is installed, build defers to it; otherwise build runs its own quick brainstorm. Both produce the same \u0060.agentera/vision.yaml\u0060 shape — the capabilities are interchangeable at the artifact level.\n\n### Vision is informed by discuss\n\nDecision entries provide context for vision refinement: what choices have been made and why. When vision detects that decisions have shifted thinking away from the current vision, it surfaces this during refine mode.\n\n### Vision is informed by profile\n\nThe decision profile calibrates the vision conversation: what patterns the user values, what principles they've established across projects, what they resist. High-confidence entries (CS1-CS2, 70+) become proposed principles in the vision.\n\n### Vision is informed by research\n\nResearch that shifts the project's direction lands in the decisions artifact; vision picks up the captured insight during refine mode.\n\n### Vision is informed by audit\n\nThe health artifact tells vision what structural realities constrain the vision. A project with D-grade architecture may need a vision adjustment, or the vision may confirm that the architecture needs to change.\n\n### Vision reads design output\n\nVision reads DESIGN.md (in Create Step 1) for the project's visual identity. The \u0060identity\u0060 section SHOULD cohere with this visual system. Vision never writes DESIGN.md; design owns all writes.\n\n### Vision reads document output\n\nDOCS.md provides artifact path resolution for the canonical vision artifact and signals what documentation exists in the project.\n\n### Vision feeds plan\n\nWhen a new or refined vision changes the project's direction, plan can produce a plan to realign the codebase with the updated vision.\n\n### Invocation guidance (consumer perspective)\n\n**New project**: invoke ⛥ vision for deep creation of the vision artifact through codebase exploration, domain research, and aspirational conversation. Then ≡ plan to plan the first features (if complex), then ⧉ build to start building.\n\n**Existing project without a vision**: invoke ⛥ vision to read the codebase, understand what exists, then push the user to articulate where it should go.\n\n**Vision refinement**: invoke ⛥ vision to detect the existing vision artifact, offer refine mode, read progress and decisions since last update, propose informed changes.\n\n**Without vision installed**: build's built-in quick brainstorm creates a workable vision artifact. Vision adds depth and stewardship but is not required for the suite to function.\n"`);
 export default instructions;
-//# sourceMappingURL=instructions.js.map

package/dist/cli/appContext.js

@@ -230,4 +230,3 @@ export function artifactPath(info, schemaName) {
     const record = info.record;
     return resolveArtifactPathLocal(info.path, schemaName, record ?? null);
 }
-//# sourceMappingURL=appContext.js.map

package/dist/cli/argvalidate.js

@@ -38,4 +38,3 @@ export function pathStem(p) {
         return base;
     return base.slice(0, dot);
 }
-//# sourceMappingURL=argvalidate.js.map

package/dist/cli/capabilityContext/benchmark.js

@@ -5,7 +5,8 @@ import { resolveProfileDirOverride, resolveXdgDataHome } from "../../core/envPat
 import { expanduser } from "../../core/paths.js";
 import { sourceProvenance, uniqueList } from "./shared.js";
 import { STATE_FAMILY_FALLBACK_COMMANDS } from "./types.js";
-export const BENCHMARK_CONTEXT_CMD = "agentera prime --context optimize --format json";
+import { preCutoverCommand } from "../preCutoverCommand.js";
+export const BENCHMARK_CONTEXT_CMD = preCutoverCommand("prime --context optimize --format json");
 export const BENCHMARK_LATEST_REPORT_LABEL = "startup_benchmark_latest_report";
 export const BENCHMARK_HISTORY_LABEL = "startup_benchmark_history";
 export const BENCHMARK_CONTEXT_SOURCE_LABELS = [BENCHMARK_LATEST_REPORT_LABEL, BENCHMARK_HISTORY_LABEL];
@@ -504,7 +505,7 @@ export function optimizeBenchmarkContext(capability) {
         ...(recommendation.caveats ?? []),
         ...(manualRefresh.caveats ?? []),
     ]);
-    const fallbackCommands = [STATE_FAMILY_FALLBACK_COMMANDS.docs, "agentera state query --list-artifacts --format json"];
+    const fallbackCommands = [STATE_FAMILY_FALLBACK_COMMANDS.docs, preCutoverCommand("state query --list-artifacts --format json")];
     return {
         capability: "optimize",
         benchmark_source: {
@@ -530,7 +531,7 @@ export function optimizeBenchmarkContext(capability) {
             complete_for_benchmark_context: complete,
             caveated: caveats.length > 0,
             raw_artifact_reads_required: false,
-            raw_artifact_read_policy: "Use this benchmark_context from `agentera prime --context optimize --format json` first. " +
+            raw_artifact_read_policy: `Use this benchmark_context from \`${preCutoverCommand("prime --context optimize --format json")}\` first. ` +
                 "If incomplete, follow fallback_commands and manual_refresh before any last-resort direct latest-report.json, " +
                 "latest-report.md, or runs.jsonl diagnostic read.",
             benchmark_state_families: [
@@ -562,4 +563,3 @@ export function optimizeBenchmarkContext(capability) {
         },
     };
 }
-//# sourceMappingURL=benchmark.js.map

package/dist/cli/capabilityContext/bespoke.js

@@ -42,4 +42,3 @@ export function bespokeCapabilityContexts(capabilityName, state, buildRequest =
         execution_context: buildExecutionContext(capabilityName, schemas, plan, progress, health, todoItems, docs, profile, bundle, projectRoot, buildRequest),
     };
 }
-//# sourceMappingURL=bespoke.js.map

package/dist/cli/capabilityContext/build.js

@@ -6,8 +6,10 @@ import { progressVerificationSummary } from "./progress.js";
 import { STATE_FAMILY_FALLBACK_COMMANDS, STATE_FAMILY_LIST_COMMANDS } from "./types.js";
 import { planLifecycleState } from "../planLifecycleState.js";
 import { discoverProjectVerification } from "./projectVerification.js";
-const TRANSIENT_BUILD_INPUT_COMMAND = "agentera prime --context build --input <file|-> --format json";
-const TRANSIENT_BUILD_STDIN_COMMAND = "agentera prime --context build --input - --format json";
+import { deferredStartupFamilies } from "./startupAggregation.js";
+import { preCutoverCommand } from "../preCutoverCommand.js";
+const TRANSIENT_BUILD_INPUT_COMMAND = preCutoverCommand("prime --context build --input <file|-> --format json");
+const TRANSIENT_BUILD_STDIN_COMMAND = preCutoverCommand("prime --context build --input - --format json");
 function transientSourceProvenance(request, field) {
     return {
         source_family: "transient_build_execution_request",
@@ -49,10 +51,9 @@ export function buildExecutionContext(capability, schemas, plan, progress, healt
         mode = "blocked_or_dependency_unready";
     let stateCaveats = [];
     let fallbackCommands = [];
-    for (const family of (capabilityContract.missing_state_families ?? [])) {
-        stateCaveats.push(`${family} state is not included in prime --context startup context.`);
+    for (const family of deferredStartupFamilies(capabilityContract)) {
+        stateCaveats.push(`${family} detail is deferred from prime --context startup.`);
     }
-    fallbackCommands.push(...(capabilityContract.cli_fallback ?? []));
     if (lifecycle.status === "degraded") {
         stateCaveats.push(...(lifecycle.caveats ?? []));
         fallbackCommands.push(STATE_FAMILY_FALLBACK_COMMANDS.plan);
@@ -83,7 +84,7 @@ export function buildExecutionContext(capability, schemas, plan, progress, healt
     }
     if (changelogBoundary.status !== "available") {
         stateCaveats.push(...(changelogBoundary.caveats ?? []));
-        fallbackCommands.push("agentera state query changelog --format json");
+        fallbackCommands.push(preCutoverCommand("state query changelog --format json"));
     }
     if (profile.status !== "valid") {
         stateCaveats.push("profile-derived state is unavailable in prime --context response.");
@@ -206,7 +207,7 @@ export function buildExecutionContext(capability, schemas, plan, progress, healt
             remote_push_allowed: false,
             commit_allowed_only_with_explicit_user_request: true,
             tag_or_publication_allowed: false,
-            source_provenance: sourceProvenance("execution_context", "agentera prime --context build --format json", "git_boundary"),
+            source_provenance: sourceProvenance("execution_context", preCutoverCommand("prime --context build --format json"), "git_boundary"),
         },
         plan_completion_sweep: sweep,
         plan_lifecycle_state: lifecycle,
@@ -218,8 +219,6 @@ export function buildExecutionContext(capability, schemas, plan, progress, healt
             raw_artifact_reads_required: false,
             raw_artifact_read_policy: "Use this execution_context and included status state first. Run listed routine/query CLI fallback commands " +
                 "for missing or incomplete execution state; raw artifact reads are last-resort diagnostics, not normal Build startup behavior.",
-            included_state_families: capabilityContract.included_state_families ?? [],
-            missing_state_families: capabilityContract.missing_state_families ?? [],
             required_execution_state: requiredState,
             missing_required_execution_state: missingRequired,
             fallback_commands: fallbackCommands,
@@ -241,4 +240,3 @@ export function buildExecutionContext(capability, schemas, plan, progress, healt
         },
     };
 }
-//# sourceMappingURL=build.js.map

package/dist/cli/capabilityContext/closeout.js

@@ -8,6 +8,8 @@ import { closeoutChangelogBoundary } from "./planState.js";
 import { progressVerificationSummary } from "./progress.js";
 import { decisionReviewPressure } from "./evidence.js";
 import { STATE_FAMILY_FALLBACK_COMMANDS } from "./types.js";
+import { deferredStartupFamilies } from "./startupAggregation.js";
+import { preCutoverCommand } from "../preCutoverCommand.js";
 export function closeoutArtifactMappings(docs) {
     const mapping = asList(docs.mapping);
     const ok = Boolean(docs.exists) && mapping.length > 0;
@@ -134,14 +136,14 @@ export function closeoutReleaseBoundary(changelogBoundary, bundle) {
             remote_push: "not_recorded_in_cli_state",
             remote_checks_performed: false,
             registry_checks_performed: false,
-            source_provenance: sourceProvenance("closeout_context", "agentera prime --context document --format json", "release_boundary.publication_evidence"),
+            source_provenance: sourceProvenance("closeout_context", preCutoverCommand("prime --context document --format json"), "release_boundary.publication_evidence"),
             caveats: ["Closeout context does not contact remotes or package registries."],
         },
         app_refresh_evidence: {
             installed_app_status: bundle.status ?? null,
             refresh: "not_recorded_in_cli_state",
             approval_recorded: false,
-            source_provenance: sourceProvenance("status", "agentera prime --format json", "app.status"),
+            source_provenance: sourceProvenance("status", preCutoverCommand("prime --format json"), "app.status"),
         },
         caveats,
     };
@@ -169,8 +171,8 @@ export function documentCloseoutContext(capability, schemas, plan, progress, tod
     };
     const missingRequired = Object.entries(requiredState).filter(([, present]) => !present).map(([k]) => k);
     let stateCaveats = [];
-    for (const family of (capabilityContract.missing_state_families ?? [])) {
-        stateCaveats.push(`${family} state is not included in prime --context startup context.`);
+    for (const family of deferredStartupFamilies(capabilityContract)) {
+        stateCaveats.push(`${family} detail is deferred from prime --context startup.`);
     }
     for (const component of [artifactMappings, versionPolicy, todoBlockers, changelogBoundary, releaseBoundary, progressEvidence, benchmarkEvidence, reviewPressure]) {
         stateCaveats.push(...(component.caveats ?? []));
@@ -186,9 +188,8 @@ export function documentCloseoutContext(capability, schemas, plan, progress, tod
         STATE_FAMILY_FALLBACK_COMMANDS.todo,
         STATE_FAMILY_FALLBACK_COMMANDS.docs,
         STATE_FAMILY_FALLBACK_COMMANDS.progress,
-        "agentera state query changelog --format json",
-        "agentera state query --list-artifacts --format json",
-        ...(capabilityContract.cli_fallback ?? []),
+        preCutoverCommand("state query changelog --format json"),
+        preCutoverCommand("state query --list-artifacts --format json"),
     ]);
     return {
         capability: "document",
@@ -208,8 +209,6 @@ export function documentCloseoutContext(capability, schemas, plan, progress, tod
             raw_artifact_reads_required: false,
             raw_artifact_read_policy: "Use this closeout_context and included status state first. Run listed routine/query CLI fallback commands " +
                 "for missing or incomplete closeout state; raw artifact reads are last-resort diagnostics, not normal closeout behavior.",
-            included_state_families: capabilityContract.included_state_families ?? [],
-            missing_state_families: capabilityContract.missing_state_families ?? [],
             closeout_state_families: ["docs", "todo", "changelog", "progress", "benchmark_evidence", "decisions"],
             required_closeout_state: requiredState,
             missing_required_closeout_state: missingRequired,
@@ -232,4 +231,3 @@ export function documentCloseoutContext(capability, schemas, plan, progress, tod
         },
     };
 }
-//# sourceMappingURL=closeout.js.map

package/dist/cli/capabilityContext/contract.js

@@ -3,33 +3,11 @@ import path from "node:path";
 import { loadYamlMapping } from "../../core/yaml.js";
 import { activeAppModel, discoverSchemasDir } from "../appContext.js";
 import { capabilityStartupCommand } from "../../capabilities/index.js";
-import { PLAN_COMPLETED_PLAN_ARCHIVE_CONFIRMATION, PLAN_INSTRUCTIONS_AUTHORITY_EXCEPTIONS, PLAN_PLANNING_LEVELS, PLAN_RAW_PLAN_ACCESS_ALLOWED_FOR, PLAN_STARTUP_CONTRACT_VERSION, PLAN_STEP_VERBS, PLAN_TASK_COHERENCE_RULE, STARTUP_ENVELOPE_STATE_FAMILIES, STATE_FAMILY_FALLBACK_COMMANDS, } from "./types.js";
+import { PLAN_COMPLETED_PLAN_ARCHIVE_CONFIRMATION, PLAN_INSTRUCTIONS_AUTHORITY_EXCEPTIONS, PLAN_PLANNING_LEVELS, PLAN_RAW_PLAN_ACCESS_ALLOWED_FOR, PLAN_STARTUP_CONTRACT_VERSION, PLAN_STEP_VERBS, PLAN_TASK_COHERENCE_RULE, STATE_FAMILY_FALLBACK_COMMANDS, } from "./types.js";
 import { CAPABILITY_INSTRUCTIONS, capabilityInstructionModulePath } from "../../capabilities/index.js";
 import { isFile, pyRepr, appendUnique } from "./shared.js";
-import { stateWriterContract } from "../../state/write/operations.js";
-import { loadStateRetrievalAuthority } from "../../state/retrievalAuthority.js";
-function stateRetrievalContract(needs) {
-    const surfaces = [
-        ...(needs.includes("plan") ? ["plan_tasks", "plans"] : []),
-        ...(needs.includes("experiments") ? ["experiments"] : []),
-    ];
-    if (surfaces.length === 0)
-        return null;
-    const loaded = loadStateRetrievalAuthority();
-    const retrieval = loaded.retrieval;
-    const boundaries = [
-        ...(needs.includes("plan") ? ["plan", "plan_task"] : []),
-        ...(needs.includes("experiments") ? ["experiment"] : []),
-    ];
-    return {
-        authority: loaded.authority,
-        schema_version: retrieval.schema_version,
-        status: retrieval.status,
-        commands: Object.fromEntries(surfaces.map((surface) => [surface, retrieval.commands[surface]])),
-        collections: retrieval.collections
-            .filter((entry) => boundaries.includes(String(entry.boundary ?? entry.artifact))),
-    };
-}
+import { startupAvailabilityProjection } from "./startupAggregation.js";
+import { preCutoverCommand } from "../preCutoverCommand.js";
 export function capabilityInstructionContractPath() {
     const model = activeAppModel();
     const active = path.join(String(model.authoritativeRoot ?? model.activeBundleRoot), "references", "cli", "capability-instruction-contract.yaml");
@@ -90,12 +68,12 @@ export function planStartupContract() {
     return {
         schemaVersion: PLAN_STARTUP_CONTRACT_VERSION,
         status: "implemented_compact_normal_startup_contract",
-        canonical_surface: "agentera prime --context plan --format json",
+        canonical_surface: capabilityStartupCommand("plan"),
         bounded: true,
         instructions_runtime_read_required: false,
         instructions_authority: {
             normal_startup: "Use this compact context for normal Plan execution startup; " +
-                "shell out to `agentera prime --context plan --format json` for the full Plan instructions.",
+                `shell out to \`${capabilityStartupCommand("plan")}\` for the full Plan instructions.`,
             read_plan_instructions_when: PLAN_INSTRUCTIONS_AUTHORITY_EXCEPTIONS,
         },
         planning: {
@@ -134,7 +112,7 @@ export function planStartupContract() {
         seam_decision: {
             selected: "prime --context",
             not_changed: [
-                { surface: "agentera schema --format json", reason: "runtime/schema command discovery, not capability workflow startup context" },
+                { surface: preCutoverCommand("schema --format json"), reason: "runtime/schema command discovery, not capability workflow startup context" },
                 { surface: "dispatcher guidance", reason: "route and CLI-state separation guidance, not a bounded Plan workflow payload" },
             ],
         },
@@ -189,26 +167,13 @@ export function capabilityContext(capability) {
         return null;
     const [inventory, error] = capabilityArtifactInventory(capability);
     const needs = inventory.read_needs;
-    const writeTargets = inventory.write_targets;
-    const missing = needs.filter((name) => !STARTUP_ENVELOPE_STATE_FAMILIES.has(name));
-    const cliFallback = missing.filter((name) => name in STATE_FAMILY_FALLBACK_COMMANDS).map((name) => STATE_FAMILY_FALLBACK_COMMANDS[name]);
     const context = {
         capability,
         first_invocation_read: firstInvocationReadMetadata(capability),
-        declared_state_needs: needs,
-        declared_write_targets: writeTargets,
-        write_contract: stateWriterContract(writeTargets, "compact"),
-        retrieval_contract: stateRetrievalContract(needs),
-        artifact_inventory: inventory,
-        included_state_families: needs.filter((name) => STARTUP_ENVELOPE_STATE_FAMILIES.has(name)),
-        missing_state_families: missing,
-        cli_fallback: cliFallback,
-        raw_artifact_read_policy: "Use the included state families from this prime --context response first. " +
-            "If needed families are missing or CLI state is incomplete, run the CLI fallback commands before raw file access.",
+        availability: startupAvailabilityProjection(needs),
         schema_error: error,
     };
     if (capability === "plan")
         context.startup_contract = planStartupContract();
     return context;
 }
-//# sourceMappingURL=contract.js.map

package/dist/cli/capabilityContext/evidence.js

@@ -6,6 +6,8 @@ import { docsConventions, sourceProvenance, uniqueList, hasRecordedValue } from
 import { selectEvidenceTarget, taskByRef } from "./planState.js";
 import { progressVerificationSummary, retryState } from "./progress.js";
 import { STATE_FAMILY_FALLBACK_COMMANDS, STATE_FAMILY_LIST_COMMANDS } from "./types.js";
+import { deferredStartupFamilies } from "./startupAggregation.js";
+import { preCutoverCommand } from "../preCutoverCommand.js";
 export function dateFromIsoUtc(s) {
     const m = /^(\d{4})-(\d{2})-(\d{2})/.exec(s.trim());
     if (!m)
@@ -88,7 +90,7 @@ export function evidenceTodoState(schemas, todoItems) {
     };
 }
 export function evidenceProtectedStateChecks() {
-    const source = sourceProvenance("evidence_context", "agentera prime --context audit --format json", "protected_state_checks");
+    const source = sourceProvenance("evidence_context", preCutoverCommand("prime --context audit --format json"), "protected_state_checks");
     return {
         status: "not_checked_by_design",
         allowed_status_values: ["verified_local", "not_checked_by_design", "requires_manual_check", "unavailable"],
@@ -119,7 +121,7 @@ export function evidenceVersionChecks(docs) {
     const versionFiles = asList(conventions.version_files);
     const semverPolicy = conventions.semver_policy && typeof conventions.semver_policy === "object" && !Array.isArray(conventions.semver_policy) ? conventions.semver_policy : {};
     const source = sourceProvenance("docs", STATE_FAMILY_FALLBACK_COMMANDS.docs, "summary.conventions");
-    const ec = (field) => sourceProvenance("evidence_context", "agentera prime --context audit --format json", field);
+    const ec = (field) => sourceProvenance("evidence_context", preCutoverCommand("prime --context audit --format json"), field);
     const checks = [
         {
             name: "docs_version_policy",
@@ -340,31 +342,31 @@ export function auditEvidenceContext(capability, schemas, plan, progress, health
     const reviewPressure = decisionReviewPressure(decisionHistory);
     let stateCaveats = [];
     const attributedRisks = [];
-    for (const family of (capabilityContract.missing_state_families ?? [])) {
-        const message = `${family} state is not included in prime --context startup context.`;
+    for (const family of deferredStartupFamilies(capabilityContract)) {
+        const message = `${family} detail is deferred from prime --context startup.`;
         stateCaveats.push(message);
-        attributedRisks.push(residualRiskEntry("missing_state_family", "caveated", message, sourceProvenance("prime", "agentera prime --context audit --format json", "source_contract.capability_context.missing_state_families")));
+        attributedRisks.push(residualRiskEntry("deferred_state_detail", "caveated", message, sourceProvenance("prime", preCutoverCommand("prime --context audit --format json"), "capability_context.startup.availability")));
     }
     if (bundle.status !== "up_to_date") {
         const message = "Agentera app files are not up to date; this is a caveat, not approval to repair or update app files.";
         stateCaveats.push(message);
-        attributedRisks.push(residualRiskEntry("installed_app_state", "caveated", message, sourceProvenance("status", "agentera prime --format json", "app.status")));
+        attributedRisks.push(residualRiskEntry("installed_app_state", "caveated", message, sourceProvenance("status", preCutoverCommand("prime --format json"), "app.status")));
     }
     if (profile.status !== "valid") {
         const message = "profile-derived state is unavailable in prime --context response.";
         stateCaveats.push(message);
-        attributedRisks.push(residualRiskEntry("profile_state", "unavailable", message, sourceProvenance("status", "agentera prime --format json", "profile.status")));
+        attributedRisks.push(residualRiskEntry("profile_state", "unavailable", message, sourceProvenance("status", preCutoverCommand("prime --format json"), "profile.status")));
     }
     else if (profile.stale === true) {
         const message = "profile-derived state is stale; this is a caveat, not approval to refresh profile state.";
         stateCaveats.push(message);
-        attributedRisks.push(residualRiskEntry("profile_state", "caveated", message, sourceProvenance("status", "agentera prime --format json", "profile.stale")));
+        attributedRisks.push(residualRiskEntry("profile_state", "caveated", message, sourceProvenance("status", preCutoverCommand("prime --format json"), "profile.stale")));
     }
     for (const component of [evaluationTarget, planCriteria, progressVerification, docsState, healthState, todoState, protectedStateChecks, versionChecks]) {
         for (const caveat of (component.caveats ?? [])) {
             stateCaveats.push(caveat);
             // cast: component source_provenance comes from evidence builders backed by parsed artifact/decision state
-            const componentSp = component.source_provenance ?? sourceProvenance("evidence_context", "agentera prime --context audit --format json");
+            const componentSp = component.source_provenance ?? sourceProvenance("evidence_context", preCutoverCommand("prime --context audit --format json"));
             attributedRisks.push(residualRiskEntry("evidence_family", "caveated", caveat, componentSp));
         }
     }
@@ -407,8 +409,7 @@ export function auditEvidenceContext(capability, schemas, plan, progress, health
         STATE_FAMILY_FALLBACK_COMMANDS.docs,
         STATE_FAMILY_FALLBACK_COMMANDS.health,
         STATE_FAMILY_FALLBACK_COMMANDS.todo,
-        "agentera state query --list-artifacts --format json",
-        ...(capabilityContract.cli_fallback ?? []),
+        preCutoverCommand("state query --list-artifacts --format json"),
     ]);
     return {
         capability: "audit",
@@ -436,8 +437,6 @@ export function auditEvidenceContext(capability, schemas, plan, progress, health
             raw_artifact_reads_required: false,
             raw_artifact_read_policy: "Use this evidence_context and included status state first. Run listed routine/query CLI fallback commands " +
                 "for missing or incomplete evidence state; raw artifact reads are last-resort diagnostics, not normal evaluation startup behavior.",
-            included_state_families: capabilityContract.included_state_families ?? [],
-            missing_state_families: capabilityContract.missing_state_families ?? [],
             required_evidence_state: requiredState,
             missing_required_evidence_state: missingRequired,
             fallback_commands: fallbackCommands,
@@ -462,4 +461,3 @@ export function auditEvidenceContext(capability, schemas, plan, progress, health
         },
     };
 }
-//# sourceMappingURL=evidence.js.map

package/dist/cli/capabilityContext/index.js

@@ -1,4 +1,3 @@
 export { CAPABILITY_NAMES } from "./types.js";
 export { validatePrimeCapability } from "./shared.js";
 export { buildPrimeCapabilityContextPayload } from "./startup.js";
-//# sourceMappingURL=index.js.map