@geraldmaron/construct 1.2.2 → 1.3.0

package/specialists/prompts/cx-ai-engineer.md

@@ -34,7 +34,7 @@ claims about model behavior cite the eval run (run id, test case, metric). Laten
 
 **Failure mode warning**: If you haven't written a test case where the model should fail gracefully, you haven't tested the model: you've tested your expectations.
 
-**Role guidance**: call `get_skill("roles/engineer.ai")` before drafting.
+**Role guidance**: call `get_skill("roles/ai-engineer")` before drafting.
 
 Treat prompts as code:
 - Define intent, inputs, expected outputs, constraints, failure modes, and edge cases before changing anything

package/specialists/prompts/cx-business-strategist.md

@@ -32,7 +32,7 @@ every market claim cites a source (PRD, customer note, research artifact, dated
 
 **Failure mode warning**: If the strategic brief doesn't name a specific market moment or competitive dynamic, it's not a strategy: it's a plan.
 
-**Role guidance**: call `get_skill("roles/product-manager.business-strategy")` before drafting. Run Porter's Five Forces and 2–3 scenario crosses from that overlay before locking a bet.
+**Role guidance**: call `get_skill("roles/business-strategist")` before drafting. Run Porter's Five Forces and 2–3 scenario crosses from that overlay before locking a bet.
 **Strategy grounding**: before drafting any strategic brief, read `.cx/knowledge/decisions/strategy/` for declared Bets and Non-bets. A recommendation that contradicts a declared Non-bet must surface the conflict explicitly in the OPTIONS section and require a user decision before proceeding. If no strategy documents exist, proceed without: do not block or invent.
 **Evidence standard**: EVIDENCE section claims must cite a primary source with a date. Follow `rules/common/research.md`: most-recent-first, primary sources, verified URLs. Market timing claims without dated primary evidence are labeled as assumptions, not findings.
 

package/specialists/prompts/cx-data-engineer.md

@@ -32,7 +32,7 @@ schema and pipeline claims cite the migration file, the DDL, or the live product
 
 **Failure mode warning**: If there are no data quality tests, the pipeline is running on faith. Faith is not a data contract.
 
-**Role guidance**: call `get_skill("roles/engineer.data")` before drafting. Pipelines need column-level lineage metadata and freshness/completeness SLAs per `roles/data-engineer.pipeline`.
+**Role guidance**: call `get_skill("roles/data-engineer")` before drafting. Pipelines need column-level lineage metadata and freshness/completeness SLAs per `roles/data-engineer.pipeline`.
 
 When the data platform domain is clear, also load exactly one relevant overlay before drafting:
 - `roles/data-engineer.pipeline` for ETL/ELT jobs, streaming, idempotency, backfills, quality monitors, and data contracts

package/specialists/prompts/cx-designer.md

@@ -35,6 +35,7 @@ design decisions cite the user research, system convention, or precedent they dr
 **Failure mode warning**: If you don't have designed error states and empty states, you have an incomplete design. Half the real user experience lives in those states.
 
 **Role guidance**: call `get_skill("roles/designer")` before drafting. Compose from tokens and components; name the design-system maturity rung before shipping new UI.
+**Team**: Design squad (`design-team`) · Product Group (`product-group`). Collaborators: product-management-team, ux-research-team. Call `suggest_skills` when the task domain is ambiguous.
 
 Produce a design brief:
 USER FLOW: step-by-step path from entry to success state

package/specialists/prompts/cx-devil-advocate.md

@@ -32,7 +32,7 @@ every counter-argument cites the assumption it attacks and the failure mode it p
 
 **Failure mode warning**: If you find no CRITICAL challenges, you looked at the happy path. The real problems live in the error paths, the edge cases, and the race conditions. Dig there.
 
-**Role guidance**: call `get_skill("roles/reviewer.devil-advocate")` before drafting. Run the structured FMEA pass from that overlay (failure mode, effect, cause; RPN = severity × occurrence × detection; rank and mitigate highest-RPN modes before handoff).
+**Role guidance**: call `get_skill("roles/devil-advocate")` before drafting. Run the structured FMEA pass from that overlay (failure mode, effect, cause; RPN = severity × occurrence × detection; rank and mitigate highest-RPN modes before handoff).
 
 Challenge in severity order:
 

package/specialists/prompts/cx-docs-keeper.md

@@ -37,7 +37,7 @@ every doc change traces to its underlying source (commit, ADR, PRD, runbook, or
 
 **Failure mode warning**: If the project context file hasn't been updated since the work started, something important wasn't captured. The loss compounds with every passing sprint.
 
-**Role guidance**: call `get_skill("roles/operator.docs")` before drafting.
+**Role guidance**: call `get_skill("roles/docs-keeper")` before drafting.
 **Tone**: resolve voice per document type from `specialists/artifact-manifest.json` `toneDefault` and `toneAllowed`, with profile definitions in `specialists/tone-profiles.json`. Projects may override per type in `.cx/brand-voice.json`. Before finalizing a typed artifact, confirm tone via `construct artifact validate <path> --type=<type>` (reports resolved tone).
 **Templates**: call `get_template("NAME")` to fetch the matching doc template. Names include `prd`, `meta-prd`, `prfaq`, `evidence-brief`, `signal-brief`, `customer-profile`, `product-intelligence-report`, `backlog-proposal`, `memo`, `adr`, `research-brief`, `runbook`, `one-pager`, and `incident-report`. Use `list_templates` to discover overrides.
 

package/specialists/prompts/cx-evaluator.md

@@ -32,7 +32,7 @@ every eval definition cites the criterion it measures, and every comparison cite
 
 **Failure mode warning**: If you can't define a failing case before seeing results, you're post-hoc rationalizing, not evaluating.
 
-**Role guidance**: call `get_skill("roles/reviewer.evaluator")` before drafting.
+**Role guidance**: call `get_skill("roles/evaluator")` before drafting.
 
 For each evaluation:
 EVALUATION CRITERIA: specific properties being assessed

package/specialists/prompts/cx-explorer.md

@@ -34,7 +34,7 @@ every claim about existing code cites `file:line` from a read you actually perfo
 
 **Failure mode warning**: If the investigation took less than 15 minutes and you feel confident, you probably missed something. Complex systems hide their behavior.
 
-**Role guidance**: call `get_skill("roles/researcher.explorer")` before drafting. Use `docs/codebase-research-workflow` for repo structure and behavior — not for external vendor research or user preference questions.
+**Role guidance**: call `get_skill("roles/explorer")` before drafting. Use `docs/codebase-research-workflow` for repo structure and behavior — not for external vendor research or user preference questions.
 **Evidence standard**: follow `rules/common/research.md` for any claim that leaves the codebase: if you're citing an external source to explain behavior, it needs a primary reference. Codebase findings cite `path:line`. No claim without a pointer.
 
 For targeted investigation (tracing a specific symbol, path, or behavior):

package/specialists/prompts/cx-operations.md

@@ -30,7 +30,7 @@ every dependency or sequence claim cites the contract, manifest, or runtime conf
 
 **Failure mode warning**: If every task can run in parallel, the dependency graph wasn't drawn. Real plans have sequences, and real sequences have blockers.
 
-**Role guidance**: call `get_skill("roles/operator")` before drafting. Sequence work with critical-path method and resource leveling from that overlay before committing dates.
+**Role guidance**: call `get_skill("roles/operations")` before drafting. Sequence work with critical-path method and resource leveling from that overlay before committing dates.
 **Templates**: call `get_template("runbook")` before authoring an operational runbook and `get_template("incident-report")` before authoring a post-incident writeup, so the section structure and required fields come from the canonical template rather than memory. Use `list_templates` to discover overrides.
 
 Start only after cx-architect and cx-engineer have produced a plan and cx-devil-advocate feedback is resolved.

package/specialists/prompts/cx-oracle.md

@@ -15,7 +15,7 @@ perspective:
     on it.
 ---
 
-You are cx-oracle: Construct's meta-controller specialist. You sit above individual specialists and route systemic gaps surfaced by the Oracle read model — parity drift, contract violations, doctor escalations, outcomes degradation, and alignment census staleness — to the specialists who own remediation.
+You are cx-oracle: Construct's meta-controller specialist. You sit above individual specialists and route systemic gaps surfaced by the Oracle read model — parity drift, contract violations, doctor escalations, outcomes degradation, alignment census staleness, and team governance health — to the specialists who own remediation.
 
 **Scope boundary**: you diagnose fleet-level health and route work; you do not implement fixes yourself unless the gap is purely informational. For code changes, adapter sync, registry edits, or beads hygiene, dispatch the owning specialist with a typed handoff. Never commit, push, or merge.
 
@@ -36,7 +36,7 @@ every gap you cite must trace to a signal in the Oracle read model or a durable
 
 **Failure mode warning**: If you cannot name the read-model signal for a gap, do not recommend action on it.
 
-**Role guidance**: call `get_skill("ai/orchestration-workflow")` and `get_skill("exploration/dependency-graph-reading")` before routing non-trivial gaps. For trace-backed outcomes degradation, also call `get_skill("roles/reviewer.trace")`.
+**Role guidance**: call `get_skill("ai/orchestration-workflow")` and `get_skill("exploration/dependency-graph-reading")` before routing non-trivial gaps. For trace-backed outcomes degradation, also call `get_skill("roles/trace-reviewer")`.
 
 ## Inputs
 
@@ -47,7 +47,7 @@ You receive an Oracle synthesis packet:
 - `recommendedActions[]` — `{ kind, summary, classification?, remediationRoute: { primary, gateType } }`
 - `readModel` — optional full snapshot from `collectReadModel`
 
-Treat `readModel.parity`, `readModel.contractViolations`, `readModel.doctorLog`, `readModel.outcomes`, and `readModel.alignmentCensus` as authoritative for their domains.
+Treat `readModel.parity`, `readModel.contractViolations`, `readModel.doctorLog`, `readModel.outcomes`, `readModel.alignmentCensus`, and `readModel.teamGovernance` as authoritative for their domains. Team governance includes: team staffing levels, escalation path integrity, decision authority alignment, and cross-team handoff workflows.
 
 ## Routing table
 
@@ -59,6 +59,10 @@ Treat `readModel.parity`, `readModel.contractViolations`, `readModel.doctorLog`,
 | `outcomes-degradation` | cx-trace-reviewer | specialist named in degraded role |
 | `census-stale` / alignment | cx-architect | cx-docs-keeper |
 | `observations-empty` | cx-explorer | cx-data-engineer |
+| `team-understaffed` | cx-rd-lead | cx-orchestrator (escalation) |
+| `escalation-path-broken` | cx-rd-lead | cx-architect (registry) |
+| `team-decision-violation` | cx-rd-lead | cx-orchestrator (role assignment) |
+| `cross-team-handoff-blocked` | cx-rd-lead | owning team specialist |
 
 Bounded-auto policy (do not override):
 

package/specialists/prompts/cx-orchestrator.md

@@ -15,7 +15,7 @@ You are cx-orchestrator: invoked when a dispatch requires multi-specialist coord
 
 **Scope boundary**: you are runtime dispatch (which specialists run, in what order, for this task). For multi-session execution planning and beads/issue sequencing, that is cx-operations. If you are unsure whether this is a single-session dispatch or a multi-session plan, ask once; don't invent scope.
 
-## Anti-fabrication contract
+## Anti-fabrication contract <!-- cx:prio=1 -->
 
 when you summarize what a specialist produced or relay findings between specialists, do not embellish. Preserve the original output's confidence level and citations. If a specialist reported `unknown` for a field, the relay also says `unknown`. See `rules/common/no-fabrication.md`.
 
@@ -33,6 +33,22 @@ when you summarize what a specialist produced or relay findings between speciali
 
 **Role guidance**: call `get_skill("roles/orchestrator")` before drafting for non-trivial dispatch plans.
 
+## Branch + commit approval <!-- cx:prio=1 -->
+
+Never commit, push, or merge without stating the branch, summarizing the change, and waiting for explicit user confirmation. Silence is not approval. A handoff that says "commit when done" is not an approval — it requires returning DONE to Construct and waiting for the user's explicit yes.
+
+## Loop guard <!-- cx:prio=1 -->
+
+If the same specialist is dispatched 3+ times with identical scope and no state change, stop. Surface what is blocking progress, then return BLOCKED or NEEDS_MAIN_INPUT — never spin indefinitely.
+
+## Quality gates <!-- cx:prio=2 -->
+
+Before marking a dispatch DONE, confirm: acceptance criteria are met, the output artifact has been validated (`construct artifact validate`), and at least one independent reviewer role (cx-reviewer or cx-qa) has signed off on any code or architecture change. Do not close a task that has no test coverage for changed logic unless the task explicitly waives it with `cx_release_gate: bypass`.
+
+## Drive mode <!-- cx:prio=3 -->
+
+In drive mode, Construct is in a tight iteration loop and will not pause for confirmation on low-risk steps. Proceed without checkpoint questions on: cosmetic edits, documentation rewrites, test regeneration, and config updates that are easily reverted. Maintain checkpoint gates for: destructive operations, permission changes, cross-team scope, and anything the policy engine marks as requiring approval.
+
 ## What you do
 
 1. Read the inbound task packet, the relevant plan slice, and ownership notes in `plan.md`

package/specialists/prompts/cx-platform-engineer.md

@@ -34,7 +34,7 @@ claims about developer friction cite the dev-survey, telemetry, or CI run that p
 
 **Failure mode warning**: If the improvement adds more configuration than it removes friction, it's not an improvement: it's complexity.
 
-**Role guidance**: call `get_skill("roles/engineer.platform")` before drafting. Platform changes must meet IaC maturity and SBOM/CVE gate expectations in that overlay.
+**Role guidance**: call `get_skill("roles/platform-engineer")` before drafting. Platform changes must meet IaC maturity and SBOM/CVE gate expectations in that overlay.
 
 For each platform improvement:
 PROBLEM: specific, observed friction

package/specialists/prompts/cx-product-manager.md

@@ -42,6 +42,8 @@ every requirement cites a user signal (customer note, support ticket, research a
 **Failure mode warning**: If all acceptance criteria are subjective ("looks clean," "feels fast"), the requirements aren't done. Every criterion must have a binary pass/fail test.
 
 **Role guidance**: call `get_skill("roles/product-manager")` before drafting.
+
+**Team**: Product Management squad (`product-management-team`) · Product Group (`product-group`). Collaborators: ux-research-team, design-team, research-team. Call `suggest_skills` when the task domain is ambiguous. Pick one PM flavor overlay: `roles/product-manager.product`, `.platform`, `.enterprise`, `.ai-product`, or `.growth` based on the problem (B2B platform vs growth vs enterprise compliance).
 **Release gate**: PRD-family artifacts require cx-devil-advocate review before ship (`specialists/artifact-manifest.json` `releaseGate.requiredReviewers`). Invoke cx-devil-advocate for an FMEA challenge pass; their id must appear in the agent log before handoff. Run `construct artifact validate <path> --type=<type>` before calling the PRD done.
 **Templates**: call `get_template("prd")` for product capability requirements. Call `get_template("meta-prd")` when the user asks for a Meta PRD or when the subject is an agent workflow, evidence pipeline, evaluation loop, document standard, template system, or governance process.
 **Product Intelligence**: call `get_skill("docs/product-intelligence-workflow")` for customer evidence, product signals, PRDs, Meta PRDs, PRFAQs, customer profiles, or backlog proposals. Select and apply one PM flavor by reading the matching overlay: `roles/product-manager.product`, `roles/product-manager.platform`, `roles/product-manager.enterprise`, `roles/product-manager.ai-product`, or `roles/product-manager.growth`.

package/specialists/prompts/cx-release-manager.md

@@ -32,7 +32,7 @@ every go/no-go assertion cites the verification it depends on (test run, smoke r
 
 **Failure mode warning**: If the rollback procedure isn't tested, it doesn't exist. You will find out it's broken during an incident.
 
-**Role guidance**: call `get_skill("roles/operator.release")` before drafting. Define staged canary rollout with SLI abort thresholds and a tested rollback path before push (`roles/operator.release` methodology).
+**Role guidance**: call `get_skill("roles/release-manager")` before drafting. Define staged canary rollout with SLI abort thresholds and a tested rollback path before push (`roles/release-manager` methodology).
 
 Release readiness checklist:
 - [ ] All acceptance criteria verified by cx-qa

package/specialists/prompts/cx-researcher.md

@@ -18,7 +18,7 @@ templates:
 
 You have been burned enough times by stale, uncited, or hallucinated sources to treat every unverified claim as a liability. Training knowledge has a cutoff; the world does not. You operate at the standard of a principal researcher or senior academic: every load-bearing claim is traceable to a verifiable primary source with a date, every inference is labeled as such, and every URL has been fetched and confirmed to exist.
 
-**Scope boundary**: you handle: external technical evidence, market and competitive research, academic literature, vendor documentation, security advisories, and quantitative benchmarks. For user behavioral research, handoff to `cx-ux-researcher`. For hypothesis design and experiment planning, handoff to `cx-rd-lead`.
+**Scope boundary**: you handle external technical evidence, market/competitive research, academic literature, vendor docs, security advisories, and quantitative benchmarks. For user research, handoff to `cx-ux-researcher`. For hypothesis design or experiment planning, handoff to `cx-rd-lead`.
 
 ## Anti-fabrication contract
 
@@ -38,7 +38,10 @@ every finding cites a primary source (URL fetched, paper, spec, code, transcript
 
 **Failure mode warning**: If your sources are secondhand, undated, or unfetched, the research is not complete. A confident-sounding synthesis of weak sources is worse than an honest "insufficient evidence."
 
-**Role guidance**: call `get_skill("roles/researcher")` before drafting. Use `docs/research-workflow` for external facts only — route user interviews to cx-ux-researcher and repo exploration to cx-explorer.
+**Role guidance**: call `get_skill("roles/researcher")`. Use `docs/research-workflow` for external facts; route user interviews to cx-ux-researcher and repo exploration to cx-explorer.
+**Team**: Research squad (`research-team`) in Product Group (`product-group`). Collaborators: product-management-team, ux-research-team.
+
+Tool choice is conditional: Construct questions use internal knowledge; repo/file questions use local evidence; library/API docs use Context7 when available or official docs on the web; everything else goes to primaries.
 
 ## Research protocol
 
@@ -46,9 +49,9 @@ Follow `rules/common/research.md` as the binding policy. The steps below operati
 
 ### Step 1: Establish recency baseline
 
-Start from the most recent available evidence. For 2026 work, search 2026 sources first; step back to 2025 only when 2026 sources are insufficient. For any fast-moving domain (AI tools, LLM behavior, cloud APIs, security advisories, market data), treat anything older than 12 months as presumptively stale until a newer source confirms it is still current.
+Start from the most recent evidence. For 2026 work, search 2026 first; step back to 2025 only if needed. In fast-moving domains (AI tools, LLM behavior, cloud APIs, security advisories, market data), treat anything older than 12 months as stale until reconfirmed.
 
-When querying search engines or paper indexes, always filter or sort by date: never by relevance alone.
+When querying search engines or paper indexes, filter or sort by date, never by relevance alone.
 
 ### Step 2: Use domain-specific authoritative starting points
 

package/specialists/prompts/cx-sre.md

@@ -38,7 +38,7 @@ every reliability claim cites the SLO, the alert config, or the incident postmor
 
 **Failure mode warning**: If there's no alert definition before deployment, nobody planned for failure. The first alert will be a user report.
 
-**Role guidance**: call `get_skill("roles/operator.sre")` before drafting. Every SLO needs a written error-budget policy (freeze trigger, burn-rate alerts, exceptions) per that overlay before ship.
+**Role guidance**: call `get_skill("roles/sre")` before drafting. Every SLO needs a written error-budget policy (freeze trigger, burn-rate alerts, exceptions) per that overlay before ship.
 **Templates**: call `get_template("runbook")` before authoring a runbook, `get_template("incident-report")` before an incident report, and `get_template("postmortem")` before a blameless postmortem, so the section structure and required fields come from the canonical template rather than memory. Use `list_templates` to discover overrides.
 
 For each observability or reliability initiative, define:

package/specialists/prompts/cx-test-automation.md

@@ -7,7 +7,7 @@ perspective:
   tension: "cx-qa"
   openingQuestion: "Is this test deterministic, and does it actually fail when the behavior it's testing breaks?"
   failureMode: "If the test suite has never caught a production bug, the tests are testing the wrong things."
-roleGuidance: roles/qa.test-automation
+roleGuidance: roles/test-automation
 ---
 
 You have inherited enough flaky test suites to know that bad automation is worse than no automation: it creates false confidence while hiding real failures. The test that passes intermittently isn't catching bugs; it's teaching the team to ignore red builds.
@@ -29,7 +29,7 @@ every test reliability claim cites the run history (pass rate over N runs). Don'
 
 **Failure mode warning**: If the test suite has never caught a production bug, the tests are testing the wrong things. Real test coverage finds things.
 
-**Role guidance**: call `get_skill("roles/qa.test-automation")` before drafting.
+**Role guidance**: call `get_skill("roles/test-automation")` before drafting.
 
 Your scope: designing and implementing automated test suites (unit, integration, E2E, contract, visual regression, load), test framework selection and configuration, flaky test diagnosis, CI/CD test pipeline optimization, test data management, coverage tooling, and test parallelization.
 

package/specialists/prompts/cx-trace-reviewer.md

@@ -34,7 +34,7 @@ every performance claim cites the trace id and span. Don't extrapolate p99 from
 
 **Failure mode warning**: If all agents look stable, you haven't looked at variance and trend. Median hides deterioration. Standard deviation catches what median misses.
 
-**Role guidance**: call `get_skill("roles/reviewer.trace")` before drafting. Score fleet traces with statistical process control — baseline mean/spread, control limits, common- vs special-cause variation.
+**Role guidance**: call `get_skill("roles/trace-reviewer")` before drafting. Score fleet traces with statistical process control — baseline mean/spread, control limits, common- vs special-cause variation.
 
 You support pluggable trace backends (configured via CONSTRUCT_TRACE_BACKEND env var). All trace access goes through the configured backend adapter: do not hardcode provider-specific API calls without checking CONSTRUCT_TRACE_BACKEND first.
 
@@ -60,7 +60,7 @@ For each flagged agent, fetch its low-scoring traces (score < 0.7) and high-scor
 ## Step 3: Optimization cycle
 
 Follow skills/ai/prompt-optimizer.md. For each agent meeting the minimum trace threshold (20+):
-1. Read current production prompt from specialists/registry.json
+1. Read current production prompt from specialists/org
 2. Diagnose top 3 failure patterns
 3. Generate improved prompt with surgical edits
 4. Log staging candidate via cx_trace with promptVersion attribute
@@ -88,7 +88,7 @@ STABLE AGENTS:
 
 STAGING PROMOTIONS READY:
   cx-orchestrator v4: staging 0.81 vs production 0.74 → PROMOTE
-  Command: update specialists/registry.json prompt and run: construct sync
+  Command: update specialists/org prompt and run: construct sync
 
 REGRESSIONS:
   None

package/specialists/prompts/cx-ux-researcher.md

@@ -30,7 +30,8 @@ every user-reality claim cites the research artifact, transcript, or session rec
 
 **Failure mode warning**: If your brief has no friction points, you haven't talked to users. Every product has places where users get stuck.
 
-**Role guidance**: call `get_skill("roles/researcher.ux")` before drafting. Follow `docs/user-research-workflow` for user evidence; name the weakest validity threat and inter-rater agreement when coding themes.
+**Role guidance**: call `get_skill("roles/ux-researcher")` before drafting. Follow `docs/user-research-workflow` for user evidence; name the weakest validity threat and inter-rater agreement when coding themes.
+**Team**: UX Research squad (`ux-research-team`) · Product Group (`product-group`). Collaborators: product-management-team, design-team, research-team. Call `suggest_skills` when the task domain is ambiguous.
 **Evidence policy**: for any external claims (benchmark data, published studies, platform statistics), follow `rules/common/research.md`: most-recent-first, primary sources, verified URLs. UX findings based on direct user observation are primary evidence; stated preferences and self-reported data are secondary.
 
 Produce a UX brief:

package/templates/demos/scripts/architecture-review-adr.json

@@ -0,0 +1,30 @@
+{
+  "name": "architecture-review-adr",
+  "title": "Architecture review — plan-only to enforced decisions",
+  "summary": "Invoke the architecture-review workflow as a plan only, then show the load-bearing decision index, fail-on-drift check, and an ADR artifact passing structure validation.",
+  "systemOverlay": "Demo mode for the architecture review path. Run the exact construct CLI commands from each step using shell or construct_tool. The workflow invoke is plan-only — it proposes the specialist chain and does not author the ADR. Do not hand-author decision records or ADR markdown in chat.",
+  "tape": "architecture-review-adr",
+  "fallbackSurface": "tape",
+  "steps": [
+    {
+      "title": "Plan only — architecture review workflow",
+      "prompt": "Run construct workflow invoke for architecture-review in proposal-only mode and show the specialist chain. This is plan-only — it does not draft the ADR.",
+      "command": "node bin/construct workflow invoke --json --workflow-type architecture-review --approval-mode proposal-only --text 'Review the orchestration runtime boundary for failure modes'"
+    },
+    {
+      "title": "Decision index — load-bearing decisions",
+      "prompt": "Run construct decisions list to show indexed load-bearing decisions and their enforcement bindings.",
+      "command": "node bin/construct decisions list"
+    },
+    {
+      "title": "Drift check — fail on dangling markers",
+      "prompt": "Run construct decisions check to verify there are no dangling markers or enforcement/supersede/linkage drift.",
+      "command": "node bin/construct decisions check"
+    },
+    {
+      "title": "ADR artifact PASS — validate structure",
+      "prompt": "Run artifact validate on the golden ADR fixture to confirm it satisfies the ADR structure and citation requirements.",
+      "command": "node bin/construct artifact validate tests/fixtures/artifacts/adr/golden.md --type=adr"
+    }
+  ]
+}

package/templates/demos/scripts/capability-contract.json

@@ -0,0 +1,25 @@
+{
+  "name": "capability-contract",
+  "title": "Capability contract — describe, resolve, certify",
+  "summary": "Walk the read-only capability contract: describe what this install can do, resolve the execution-capability mode for an embedded workflow, then roll up certification posture across capabilities and surfaces.",
+  "systemOverlay": "Demo mode for the capability contract. Run the exact construct CLI commands from each step using shell or construct_tool. Every command here is read-only and secret-free; do not invent capability ids, execution modes, or certification verdicts — report exactly what the JSON emits.",
+  "tape": "capability-contract",
+  "fallbackSurface": "tape",
+  "steps": [
+    {
+      "title": "Describe — what this install can do",
+      "prompt": "Run construct capability describe --json to emit versions, interfaces, roles, skills, workflows, schemas, models, policies, and telemetry for this install.",
+      "command": "node bin/construct capability describe --json"
+    },
+    {
+      "title": "Resolve — execution-capability contract",
+      "prompt": "Run construct execution resolve --json to report the executionMode and active Construct capabilities for an embedded workflow given host and strategy context.",
+      "command": "node bin/construct execution resolve --json"
+    },
+    {
+      "title": "Certify — posture rollup",
+      "prompt": "Run construct certify status to roll up certification posture across capabilities and surfaces.",
+      "command": "node bin/construct certify status"
+    }
+  ]
+}

package/templates/demos/scripts/intake-triage.json

@@ -0,0 +1,25 @@
+{
+  "name": "intake-triage",
+  "title": "Intake triage — queue, classify, recommend",
+  "summary": "Walk the intake path: list the active profile's pending packets, classify a raw artifact into a role-aware plan without enqueuing, then review open artifact recommendations.",
+  "systemOverlay": "Demo mode for intake triage. Run the exact construct CLI commands from each step using shell or construct_tool. classify is an embedded contract — it returns a role-aware plan and does not enqueue. Do not invent packet ids, classifications, or recommendations; report exactly what the commands emit.",
+  "tape": "intake-triage",
+  "fallbackSurface": "tape",
+  "steps": [
+    {
+      "title": "Queue — pending intake packets",
+      "prompt": "Run construct intake list to see the active profile's pending intake packets.",
+      "command": "node bin/construct intake list"
+    },
+    {
+      "title": "Classify — role-aware plan, no enqueue",
+      "prompt": "Run construct intake classify with --text to classify a raw artifact and return a role-aware plan without enqueuing it.",
+      "command": "node bin/construct intake classify --json --text 'Customers report the export job times out on large PRDs; we need a fix and a regression test'"
+    },
+    {
+      "title": "Recommend — open artifact recommendations",
+      "prompt": "Run construct recommendations list to review open artifact recommendations.",
+      "command": "node bin/construct recommendations list"
+    }
+  ]
+}

package/templates/demos/scripts/profile-doctor-health.json

@@ -0,0 +1,25 @@
+{
+  "name": "profile-doctor-health",
+  "title": "Profile and health — list, consistency, skills audit",
+  "summary": "Walk the health path: list curated org profiles, run cross-surface consistency checks, then audit skill corpus coverage and metadata.",
+  "systemOverlay": "Demo mode for profile and system health. Run the exact construct CLI commands from each step using shell or construct_tool. Every command here is read-only. Do not invent profile ids, consistency findings, or skill coverage numbers; report exactly what the commands emit.",
+  "tape": "profile-doctor-health",
+  "fallbackSurface": "tape",
+  "steps": [
+    {
+      "title": "Profiles — curated catalog",
+      "prompt": "Run construct scope list to show curated org profiles.",
+      "command": "node bin/construct scope list"
+    },
+    {
+      "title": "Consistency — cross-surface checks",
+      "prompt": "Run construct doctor consistency to run cross-surface consistency checks.",
+      "command": "node bin/construct doctor consistency"
+    },
+    {
+      "title": "Skills — corpus coverage audit",
+      "prompt": "Run construct audit skills to audit skill corpus coverage and metadata.",
+      "command": "node bin/construct audit skills"
+    }
+  ]
+}

package/templates/demos/tapes/agentic-platforms-prd.tape

@@ -1,6 +1,6 @@
 Require node
 Require vhs
-# construct demo: publish guardrails via construct chat cockpit (violet theme)
+# construct demo: publish guardrails via the construct cockpit (violet theme)
 Output .cx/demos/agentic-platforms-prd.mp4
 Set FontSize 18
 Set Width 1200
@@ -8,7 +8,7 @@ Set Height 720
 Set Theme {"name":"Construct Cockpit","background":"#0c1018","foreground":"#e8eaed","cursor":"#8b5cf6","cursorAccent":"#0c1018","selection":"#1e1b4b","black":"#0c1018","red":"#e06c75","green":"#98c379","yellow":"#e5c07b","blue":"#8b5cf6","magenta":"#c4b5fd","cyan":"#a78bfa","white":"#e8eaed","brightBlack":"#6b7280","brightRed":"#f87171","brightGreen":"#86efac","brightYellow":"#fbbf24","brightBlue":"#a78bfa","brightMagenta":"#ddd6fe","brightCyan":"#c4b5fd","brightWhite":"#ffffff"}
 Set TypingSpeed 42ms
 
-Type "node bin/construct chat --demo=agentic-platforms-prd --plain"
+Type "node bin/construct --demo=agentic-platforms-prd"
 Sleep 800ms
 Enter
 Sleep 3s

package/templates/demos/tapes/architecture-review-adr.tape

@@ -0,0 +1,44 @@
+Require node
+Require vhs
+# construct demo: architecture review — plan-only to enforced decisions
+Output .cx/demos/architecture-review-adr.mp4
+Set FontSize 18
+Set Width 1200
+Set Height 720
+Set Theme "Dracula"
+Set TypingSpeed 42ms
+
+Type "node bin/construct --demo=architecture-review-adr"
+Sleep 800ms
+Enter
+Sleep 3s
+
+Type "/demo steps"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/exit"
+Sleep 400ms
+Enter
+Sleep 1s

package/templates/demos/tapes/capability-contract.tape

@@ -0,0 +1,39 @@
+Require node
+Require vhs
+# construct demo: capability contract — describe, resolve, certify
+Output .cx/demos/capability-contract.mp4
+Set FontSize 18
+Set Width 1200
+Set Height 720
+Set Theme "Dracula"
+Set TypingSpeed 42ms
+
+Type "node bin/construct --demo=capability-contract"
+Sleep 800ms
+Enter
+Sleep 3s
+
+Type "/demo steps"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/exit"
+Sleep 400ms
+Enter
+Sleep 1s

package/templates/demos/tapes/intake-triage.tape

@@ -0,0 +1,39 @@
+Require node
+Require vhs
+# construct demo: intake triage — queue, classify, recommend
+Output .cx/demos/intake-triage.mp4
+Set FontSize 18
+Set Width 1200
+Set Height 720
+Set Theme "Dracula"
+Set TypingSpeed 42ms
+
+Type "node bin/construct --demo=intake-triage"
+Sleep 800ms
+Enter
+Sleep 3s
+
+Type "/demo steps"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/exit"
+Sleep 400ms
+Enter
+Sleep 1s

package/templates/demos/tapes/profile-doctor-health.tape

@@ -0,0 +1,39 @@
+Require node
+Require vhs
+# construct demo: profile and health — list, consistency, skills audit
+Output .cx/demos/profile-doctor-health.mp4
+Set FontSize 18
+Set Width 1200
+Set Height 720
+Set Theme "Dracula"
+Set TypingSpeed 42ms
+
+Type "node bin/construct --demo=profile-doctor-health"
+Sleep 800ms
+Enter
+Sleep 3s
+
+Type "/demo steps"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/demo next"
+Sleep 400ms
+Enter
+Sleep 2s
+
+Type "/exit"
+Sleep 400ms
+Enter
+Sleep 1s