@geraldmaron/construct 1.0.5 → 1.0.6

package/skills/frontend-design/state-management.md

@@ -1,5 +1,5 @@
 <!--
-skills/frontend-design/state-management.md — Frontend State Management — Use this skill when choosing state management tools, structuring application sta
+skills/frontend-design/state-management.md (Frontend State Management) Use this skill when choosing state management tools, structuring application sta
 
 Use this skill when choosing state management tools, structuring application state, or debugging state issues. ## State Categories
 -->

package/skills/frontend-design/ui-aesthetics.md

@@ -1,5 +1,5 @@
 <!--
-skills/frontend-design/ui-aesthetics.md — UI Aesthetics — Use this skill when making visual design decisions: color, typography, layout, s
+skills/frontend-design/ui-aesthetics.md (UI Aesthetics) Use this skill when making visual design decisions: color, typography, layout, s
 
 Use this skill when making visual design decisions: color, typography, layout, spacing, and visual hierarchy. ## Color
 -->

package/skills/frontend-design/ux-principles.md

@@ -1,5 +1,5 @@
 <!--
-skills/frontend-design/ux-principles.md — UX Principles — Use this skill when designing user flows, evaluating usability, or planning info
+skills/frontend-design/ux-principles.md (UX Principles) Use this skill when designing user flows, evaluating usability, or planning info
 
 Use this skill when designing user flows, evaluating usability, or planning information architecture. ## Core Heuristics
 -->

package/skills/operating/orchestration-reference.md

@@ -1,5 +1,5 @@
 <!--
-skills/operating/orchestration-reference.md — detailed orchestration reference loaded on demand.
+skills/operating/orchestration-reference.md: detailed orchestration reference loaded on demand.
 
 Holds the execution contract, handoff template, intent and work-category
 classification, parallel dispatch, horizontal routing, and efficiency
@@ -12,7 +12,7 @@ stay in sharedGuidance so they load every turn.
 
 Loaded on demand via `get_skill("operating/orchestration-reference")`.
 
-This is the detailed reference for Construct's orchestration contract. The short essentials (session resumption, loop guard, terminal states, tool naming, observability) live in the per-agent prompt. Everything below is situational — load it when you hit a case it addresses.
+This is the detailed reference for Construct's orchestration contract. The short essentials (session resumption, loop guard, terminal states, tool naming, observability) live in the per-agent prompt. Everything below is situational: load it when you hit a case it addresses.
 
 ## System model
 
@@ -20,14 +20,14 @@ Construct is the underlying orchestration system for the **current project**. Tr
 
 The two task-shaped surfaces are siblings, not duplicates:
 
-- **`.cx/workflow.json`** — single project-wide workflow file. Holds the cross-cutting task ledger and intent / category metadata. Drives `workflow_status` and `project_context` MCP tools.
-- **`.cx/task-graphs/<id>.json`** — per-incoming-signal plan generated by `construct graph from-intake <intake-id>`. One graph per triaged inbox file, one node per persona in the recommendedChain, evidence records gating `done`. See [Concepts → Intake and triage](/concepts/intake-and-triage).
+- **`.cx/workflow.json`**: single project-wide workflow file. Holds the cross-cutting task ledger and intent / category metadata. Drives `workflow_status` and `project_context` MCP tools.
+- **`.cx/task-graphs/<id>.json`**: per-incoming-signal plan generated by `construct graph from-intake <intake-id>`. One graph per triaged inbox file, one node per persona in the recommendedChain, evidence records gating `done`. See [Concepts → Intake and triage](/concepts/intake-and-triage).
 
 A signal that becomes durable cross-session work crosses over: the graph nodes are executed, the resulting work is tracked in `.cx/workflow.json` and in beads. The intake queue and task graphs are how new signals enter the loop; the workflow ledger and beads are how durable work is carried.
 
 ## Perspective architecture
 
-Each specialist carries a distinct cognitive profile shaped by professional prior, characteristic suspicion, and productive tension with adjacent roles. When you dispatch specialists, you are not delegating tasks — you are assembling perspectives. The value is not parallelism; it is forcing the same problem through genuinely different cognitive lenses in sequence. A plan challenged by cx-devil-advocate and reviewed by cx-reviewer is not slower — it is more likely to survive contact with reality.
+Each specialist carries a distinct cognitive profile shaped by professional prior, characteristic suspicion, and productive tension with adjacent roles. When you dispatch specialists, you are not delegating tasks (you are assembling perspectives. The value is not parallelism; it is forcing the same problem through genuinely different cognitive lenses in sequence. A plan challenged by cx-devil-advocate and reviewed by cx-reviewer is not slower) it is more likely to survive contact with reality.
 
 ## Execution contract
 
@@ -35,11 +35,11 @@ For every non-trivial task: classify intent, create or update `.cx/workflow.json
 
 ### Intent classes
 
-- `research` — read-only investigation
-- `implementation` — code changes
-- `investigation` — debugging, tracing
-- `evaluation` — quality gates, review
-- `fix` — bug repair
+- `research`: read-only investigation
+- `implementation`: code changes
+- `investigation`: debugging, tracing
+- `evaluation`: quality gates, review
+- `fix`: bug repair
 
 Tag every workflow task with its intent class. Let intent drive agent selection and depth of work.
 
@@ -69,24 +69,24 @@ Do not duplicate skill internals inside agent prompts. Reference the relevant sk
 
 Every producer→consumer pair has an explicit contract in `agents/contracts.json`, loaded via `lib/agent-contracts.mjs`. Specialists call the MCP tool `agent_contract` at the start of a handoff to see:
 
-- `input.mustContain` — fields the packet must carry
-- `input.schema` — JSON schema (when applicable) from `lib/schemas/`
-- `preconditions` — what must be true before work starts
-- `output.schema` / `output.shape` — expected return shape
-- `postconditions` — what must be true before marking DONE
+- `input.mustContain`: fields the packet must carry
+- `input.schema`: JSON schema (when applicable) from `lib/schemas/`
+- `preconditions`: what must be true before work starts
+- `output.schema` / `output.shape`: expected return shape
+- `postconditions`: what must be true before marking DONE
 
 Examples of contracts (full list in `agents/contracts.json`):
 
-- `researcher-to-architect` — research brief with ≥2 primary sources → decision
-- `product-manager-to-architect` — PRD handoff → decision with Rejected alternatives
-- `architect-to-devil-advocate` — framing proposal → challenge report (blocks if framing is weak)
-- `architect-to-engineer` — decision → implementation
-- `engineer-to-reviewer` — implementation → review verdict
-- `engineer-to-qa` — implementation → test report
-- `reviewer-to-security` — review with auth/secrets scope → specialized security review
-- `any-to-docs-keeper` — any DONE mutation that changed core docs → doc sync
+- `researcher-to-architect`: research brief with ≥2 primary sources → decision
+- `product-manager-to-architect`: PRD handoff → decision with Rejected alternatives
+- `architect-to-devil-advocate`: framing proposal → challenge report (blocks if framing is weak)
+- `architect-to-engineer`: decision → implementation
+- `engineer-to-reviewer`: implementation → review verdict
+- `engineer-to-qa`: implementation → test report
+- `reviewer-to-security`: review with auth/secrets scope → specialized security review
+- `any-to-docs-keeper`: any DONE mutation that changed core docs → doc sync
 
-`routeRequest` returns a `contractChain` that enumerates which of these fire for a given request. Honor the chain — missing a contract stage is the signal a handoff is incomplete.
+`routeRequest` returns a `contractChain` that enumerates which of these fire for a given request. Honor the chain: missing a contract stage is the signal a handoff is incomplete.
 
 ## Legacy handoff contract (fallback)
 
@@ -120,7 +120,7 @@ When your output directly feeds another specialist (e.g. security findings → c
 These are enforced by hooks, not advisory:
 
 - `context-watch` hook (UserPromptSubmit) injects compaction guidance at ~60% / ~80% of the context window.
-- `repeated-read-guard` hook (PreToolUse on Read) blocks broad re-reads of files already read twice in this session — steers to Grep or offset+limit.
+- `repeated-read-guard` hook (PreToolUse on Read) blocks broad re-reads of files already read twice in this session: steers to Grep or offset+limit.
 - `bash-output-logger` hook (PostToolUse on Bash) persists outputs >4KB to `~/.cx/bash-logs/` and tells the model to grep the log rather than re-run.
 
 Advisory companions:
@@ -136,11 +136,11 @@ If you reason about the same decision across two consecutive turns without a new
 
 ## Speculation rule
 
-When choosing between named options (SDK vs SDK, library vs library, pattern vs pattern), the answer comes from `context7_query-docs`, `WebFetch`, the user, or an explicit default — never from internal reasoning rounds alone.
+When choosing between named options (SDK vs SDK, library vs library, pattern vs pattern), the answer comes from `context7_query-docs`, `WebFetch`, the user, or an explicit default: never from internal reasoning rounds alone.
 
 ## Dispatch-first test
 
-If work touches 3+ files across 2+ modules, or introduces a new contract/dependency/SDK, the persona must not produce the implementation plan itself — dispatch cx-architect. In-persona implementation planning for complex work is the primary failure mode this rule exists to prevent.
+If work touches 3+ files across 2+ modules, or introduces a new contract/dependency/SDK, the persona must not produce the implementation plan itself: dispatch cx-architect. In-persona implementation planning for complex work is the primary failure mode this rule exists to prevent.
 
 ## Executive communication
 

package/skills/quality-gates/review-work.md

@@ -1,5 +1,5 @@
 <!--
-skills/quality-gates/review-work.md — Parallel Adversarial Review — Use this methodology when a change needs rigorous pre-merge validation. Five ind
+skills/quality-gates/review-work.md (Parallel Adversarial Review) Use this methodology when a change needs rigorous pre-merge validation. Five ind
 
 Use this methodology when a change needs rigorous pre-merge validation. Five independent review roles run concurrently. All must pass. ## When to use
 -->
@@ -46,13 +46,13 @@ Use this methodology when a change needs rigorous pre-merge validation. Five ind
 
 ### 5. Quality (cx-accessibility for UI; cx-trace-reviewer for non-UI)
 
-**UI changes — cx-accessibility:**
+**UI changes: cx-accessibility:**
 - Keyboard navigation
 - Screen reader compatibility
 - Color contrast and focus visibility
 - Reduced motion support
 
-**Non-UI changes — cx-trace-reviewer:**
+**Non-UI changes: cx-trace-reviewer:**
 - N+1 queries or unbounded loops
 - Memory or connection leaks
 - Missing caching for expensive operations

package/skills/quality-gates/verify-change.md

@@ -1,5 +1,5 @@
 <!--
-skills/quality-gates/verify-change.md — Verify Change — Use this skill to analyze the impact of code changes and verify documentation an
+skills/quality-gates/verify-change.md (Verify Change) Use this skill to analyze the impact of code changes and verify documentation an
 
 Use this skill to analyze the impact of code changes and verify documentation and tests are in sync. ## Change Inventory
 -->

package/skills/quality-gates/verify-module.md

@@ -1,5 +1,5 @@
 <!--
-skills/quality-gates/verify-module.md — Verify Module — Use this skill to check that a module or package is structurally complete and re
+skills/quality-gates/verify-module.md (Verify Module) Use this skill to check that a module or package is structurally complete and re
 
 Use this skill to check that a module or package is structurally complete and ready for use. ## Exports
 -->

package/skills/quality-gates/verify-quality.md

@@ -1,5 +1,5 @@
 <!--
-skills/quality-gates/verify-quality.md — Verify Quality — Use this skill to check code quality, complexity, and maintainability after chan
+skills/quality-gates/verify-quality.md (Verify Quality) Use this skill to check code quality, complexity, and maintainability after chan
 
 Use this skill to check code quality, complexity, and maintainability after changes. ## Complexity
 -->

package/skills/quality-gates/verify-security.md

@@ -1,5 +1,5 @@
 <!--
-skills/quality-gates/verify-security.md — Verify Security — Use this skill to scan code for security vulnerabilities before commits or relea
+skills/quality-gates/verify-security.md (Verify Security) Use this skill to scan code for security vulnerabilities before commits or relea
 
 Use this skill to scan code for security vulnerabilities before commits or releases. ## Scan Scope
 -->

package/skills/routing.md

@@ -1,9 +1,9 @@
 <!--
-skills/routing.md — Construct AI Agent — Skill Routing — Read the matching skill file before responding when the user's request matches t
+skills/routing.md (Construct AI Agent) Skill Routing: Read the matching skill file before responding when the user's request matches t
 
 Read the matching skill file before responding when the user's request matches trigger keywords below. ## Exploration Domain
 -->
-# Construct AI Agent — Skill Routing
+# Construct AI Agent: Skill Routing
 
 Read the matching skill file before responding when the user's request matches trigger keywords below.
 
@@ -11,7 +11,7 @@ Read the matching skill file before responding when the user's request matches t
 
 | Trigger Keywords | Skill File | Description |
 |---|---|---|
-| explore repo, map codebase, understand codebase, unfamiliar codebase, slog through, get oriented, codebase map, how is this structured, how does this work, where is X, entry point, hot path, code map | `skills/exploration/repo-map.md` | Systematic repo exploration — produce .cx/codebase-map.md |
+| explore repo, map codebase, understand codebase, unfamiliar codebase, slog through, get oriented, codebase map, how is this structured, how does this work, where is X, entry point, hot path, code map | `skills/exploration/repo-map.md` | Systematic repo exploration: produce .cx/codebase-map.md |
 
 ## Quality Gates
 
@@ -120,15 +120,15 @@ Read the matching skill file before responding when the user's request matches t
 | Trigger Keywords | Skill File | Description |
 |---|---|---|
 | init docs, create docs structure, set up documentation, docs scaffold, documentation init | `skills/docs/init-docs.md` | Initialize required project-state docs and documentation structure |
-| research X, investigate X, find evidence, gather evidence | `skills/docs/research-workflow.md` | Research workflow — question to .cx/research/ file |
-| product intelligence, customer notes, field notes, product signals, customer profile, evidence brief, signal brief, backlog proposal | `skills/docs/product-intelligence-workflow.md` | Product Intelligence workflow — evidence to product artifacts |
-| strategy, product strategy, strategic bet, non-bet, north star, time horizon, competitive positioning | `skills/docs/strategy-workflow.md` | Product strategy — read, update, and reason about the strategy store |
-| ingest evidence, ingest customer notes, ingest Slack thread, ingest support ticket, normalize field notes | `skills/docs/evidence-ingest-workflow.md` | Evidence ingest workflow — raw source to .cx/knowledge/ |
-| write a PRD, create requirements, spec out, requirements document, Meta PRD, platform PRD | `skills/docs/prd-workflow.md` | PRD workflow — requirements to docs/prd/ or docs/meta-prd/ |
-| write a PRFAQ, working backwards doc, press release FAQ | `skills/docs/prfaq-workflow.md` | PRFAQ workflow — launch narrative from PRD or evidence |
-| create Jira proposal, update Linear, backlog proposal, issue proposal | `skills/docs/backlog-proposal-workflow.md` | Backlog proposal workflow — approval-gated issue tracker changes |
-| record this decision, create an ADR, architecture decision | `skills/docs/adr-workflow.md` | ADR workflow — decision to docs/adr/ file |
-| write a runbook, document this operation, operational procedure | `skills/docs/runbook-workflow.md` | Runbook workflow — operation to docs/runbooks/ file |
+| research X, investigate X, find evidence, gather evidence | `skills/docs/research-workflow.md` | Research workflow: question to .cx/research/ file |
+| product intelligence, customer notes, field notes, product signals, customer profile, evidence brief, signal brief, backlog proposal | `skills/docs/product-intelligence-workflow.md` | Product Intelligence workflow: evidence to product artifacts |
+| strategy, product strategy, strategic bet, non-bet, north star, time horizon, competitive positioning | `skills/docs/strategy-workflow.md` | Product strategy: read, update, and reason about the strategy store |
+| ingest evidence, ingest customer notes, ingest Slack thread, ingest support ticket, normalize field notes | `skills/docs/evidence-ingest-workflow.md` | Evidence ingest workflow: raw source to .cx/knowledge/ |
+| write a PRD, create requirements, spec out, requirements document, Meta PRD, platform PRD | `skills/docs/prd-workflow.md` | PRD workflow: requirements to docs/prd/ or docs/meta-prd/ |
+| write a PRFAQ, working backwards doc, press release FAQ | `skills/docs/prfaq-workflow.md` | PRFAQ workflow: launch narrative from PRD or evidence |
+| create Jira proposal, update Linear, backlog proposal, issue proposal | `skills/docs/backlog-proposal-workflow.md` | Backlog proposal workflow: approval-gated issue tracker changes |
+| record this decision, create an ADR, architecture decision | `skills/docs/adr-workflow.md` | ADR workflow: decision to docs/adr/ file |
+| write a runbook, document this operation, operational procedure | `skills/docs/runbook-workflow.md` | Runbook workflow: operation to docs/runbooks/ file |
 | init project, new project setup, join project, set up doc structure | `skills/docs/init-project.md` | Project initialization via construct init-docs |
 
 ## Routing Rules
@@ -141,6 +141,6 @@ Read the matching skill file before responding when the user's request matches t
 
 ## Agent Roster Disambiguation
 
-**cx-engineer vs cx-platform-engineer:** cx-engineer builds product features for end users. cx-platform-engineer builds the internal platform — CI/CD, deployment tooling, developer environments, internal APIs, and reliability infrastructure. They operate in distinct domains with different quality bars (user-facing UX vs. developer ergonomics and system reliability). Use cx-platform-engineer when the subject is a platform service, internal tool, build pipeline, or infrastructure component that engineers consume, not end users.
+**cx-engineer vs cx-platform-engineer:** cx-engineer builds product features for end users. cx-platform-engineer builds the internal platform: CI/CD, deployment tooling, developer environments, internal APIs, and reliability infrastructure. They operate in distinct domains with different quality bars (user-facing UX vs. developer ergonomics and system reliability). Use cx-platform-engineer when the subject is a platform service, internal tool, build pipeline, or infrastructure component that engineers consume, not end users.
 
-**Platform domain overlays** (`roles/product-manager.platform`, `roles/architect.platform`, `roles/engineer.platform`) apply when the PRODUCT being designed or built is a platform — an API, SDK, or developer surface consumed by other developers. These are skill overlays on PM/architect/engineer roles, not routing to cx-platform-engineer. Route to cx-platform-engineer only when the work is infra/ops, not product.
+**Platform domain overlays** (`roles/product-manager.platform`, `roles/architect.platform`, `roles/engineer.platform`) apply when the PRODUCT being designed or built is a platform: an API, SDK, or developer surface consumed by other developers. These are skill overlays on PM/architect/engineer roles, not routing to cx-platform-engineer. Route to cx-platform-engineer only when the work is infra/ops, not product.

package/skills/security/blue-team.md

@@ -1,5 +1,5 @@
 <!--
-skills/security/blue-team.md — Blue Team — Use this skill when defending systems, responding to incidents, or building dete
+skills/security/blue-team.md (Blue Team) Use this skill when defending systems, responding to incidents, or building dete
 
 Use this skill when defending systems, responding to incidents, or building detection and monitoring capabilities. ## Detection Engineering
 -->

package/skills/security/code-audit.md

@@ -1,5 +1,5 @@
 <!--
-skills/security/code-audit.md — Code Audit — Use this skill when reviewing source code for security vulnerabilities through s
+skills/security/code-audit.md (Code Audit) Use this skill when reviewing source code for security vulnerabilities through s
 
 Use this skill when reviewing source code for security vulnerabilities through static analysis. ## Taint Analysis
 -->

package/skills/security/pentest.md

@@ -1,5 +1,5 @@
 <!--
-skills/security/pentest.md — Penetration Testing — Use this skill when testing web applications or APIs for security vulnerabilitie
+skills/security/pentest.md (Penetration Testing) Use this skill when testing web applications or APIs for security vulnerabilitie
 
 Use this skill when testing web applications or APIs for security vulnerabilities. ## OWASP Top 10 Checklist
 -->

package/skills/security/red-team.md

@@ -1,5 +1,5 @@
 <!--
-skills/security/red-team.md — Red Team — Use this skill when planning or executing offensive security assessments, advers
+skills/security/red-team.md (Red Team) Use this skill when planning or executing offensive security assessments, advers
 
 Use this skill when planning or executing offensive security assessments, adversary emulation, or attack simulations. ## Reconnaissance
 -->

package/skills/security/threat-intel.md

@@ -1,5 +1,5 @@
 <!--
-skills/security/threat-intel.md — Threat Intelligence — Use this skill when performing OSINT, threat modeling, or building threat intell
+skills/security/threat-intel.md (Threat Intelligence) Use this skill when performing OSINT, threat modeling, or building threat intell
 
 Use this skill when performing OSINT, threat modeling, or building threat intelligence programs. ## OSINT Collection
 -->

package/skills/security/vuln-research.md

@@ -1,5 +1,5 @@
 <!--
-skills/security/vuln-research.md — Vulnerability Research — Use this skill when analyzing binaries, fuzzing software, or developing exploits
+skills/security/vuln-research.md (Vulnerability Research) Use this skill when analyzing binaries, fuzzing software, or developing exploits
 
 Use this skill when analyzing binaries, fuzzing software, or developing exploits for security research. ## Binary Analysis
 -->

package/skills/utility/clean-code.md

@@ -1,5 +1,5 @@
 <!--
-skills/utility/clean-code.md — AI Slop Removal — Patterns and heuristics for identifying and removing AI-generated code smells. U
+skills/utility/clean-code.md (AI Slop Removal) Patterns and heuristics for identifying and removing AI-generated code smells. U
 
 Patterns and heuristics for identifying and removing AI-generated code smells. Use when cleaning up output from AI coding tools. ## Decision Tree
 -->
@@ -160,6 +160,6 @@ async function getUserById(id: string): Promise<User> { ... }
 ## Rules
 
 - Remove smell, nothing else. Do not refactor, reorganize, or add new abstractions.
-- Keep diffs minimal — one smell per change where possible.
+- Keep diffs minimal: one smell per change where possible.
 - Never change behavior. If a removal would change behavior, flag it instead.
 - Show before/after for every change.

package/templates/docs/changelog-entry.md

@@ -1,4 +1,4 @@
-# Changelog: {version} — {YYYY-MM-DD}
+# Changelog: {version}: {YYYY-MM-DD}
 
 - **Version**: {semver or date-based tag}
 - **Type**: major | minor | patch | hotfix

package/templates/docs/construct_guide.md

@@ -1,6 +1,6 @@
 # Welcome to Construct
 
-This file was generated by `construct init` to help you get oriented. It's safe to edit — Construct only writes it once, then leaves it alone.
+This file was generated by `construct init` to help you get oriented. It's safe to edit: Construct only writes it once, then leaves it alone.
 
 **Full docs:** [https://geraldmaron.github.io/construct/v2/](https://geraldmaron.github.io/construct/v2/)
 
@@ -12,7 +12,7 @@ You added Construct as a dev dependency. That gave you:
 - **Hard gates.** Every code change runs through commit-time policy: no secrets, tests green, docs current, comments lint-clean. Bypass exists for every gate but leaves an audit trail.
 - **Persistent state.** Your active work, decisions, and history survive across sessions and editor restarts.
 
-You don't need to manage any of that — it all runs locally.
+You don't need to manage any of that: it all runs locally.
 
 ## Files Construct created in your project
 
@@ -26,18 +26,18 @@ You'll see these in `git status`:
 | `.claude/settings.json` | Hooks + MCP server config. Construct keys are managed; your additions are preserved. | Carefully |
 | `.cx/` | Per-project session state (active work, recent decisions). Construct writes here. | Read-mostly |
 | `.beads/` | Issue tracker data. Use `bd <cmd>` to interact. | Via CLI |
-| `AGENTS.md` | Operating rules the agent reads at session start. | Yes — your house rules go here |
-| `plan.md` | Active work plan. Local-only (gitignored). | Yes — your current focus |
-| `docs/` | Documentation lanes (ADRs, PRDs, memos, …). | Yes — this is your team's docs |
-| `construct_guide.md` | This file. Friendly orientation. | Yes — adapt to your team |
+| `AGENTS.md` | Operating rules the agent reads at session start. | Yes: your house rules go here |
+| `plan.md` | Active work plan. Local-only (gitignored). | Yes: your current focus |
+| `docs/` | Documentation lanes (ADRs, PRDs, memos, …). | Yes: this is your team's docs |
+| `construct_guide.md` | This file. Friendly orientation. | Yes: adapt to your team |
 
 ## Where to drop information you want Construct to use
 
 Three intake paths, ordered by formality:
 
-1. **`.cx/inbox/`** — drop a file here (URL, screenshot, paste, anything). The embed daemon watches the directory; when a file lands, it ingests it into the local knowledge base within a second or two and writes a triage packet to `.cx/intake/pending/` describing the new content, its R&D classification (intake type, stage, owner persona, recommended chain), its suggested docs lane, and existing docs that overlap. The agent surfaces pending intake at the next session start and you can ask it to process them — propose updates to existing PRDs/RFCs/ADRs or scaffold new ones — based on the prepared context.
-2. **`docs/intake/`** — for proper intake batches (research notes, evidence from a meeting, raw source material). Has a template. Survives in git history.
-3. **`AGENTS.md`** — for rules and conventions you want the agent to follow every time. "We prefer functional components. Don't introduce new dependencies without flagging." Read at session start.
+1. **`.cx/inbox/`** (drop a file here (URL, screenshot, paste, anything). The embed daemon watches the directory; when a file lands, it ingests it into the local knowledge base within a second or two and writes a triage packet to `.cx/intake/pending/` describing the new content, its R&D classification (intake type, stage, owner persona, recommended chain), its suggested docs lane, and existing docs that overlap. The agent surfaces pending intake at the next session start and you can ask it to process them) propose updates to existing PRDs/RFCs/ADRs or scaffold new ones: based on the prepared context.
+2. **`docs/intake/`**: for proper intake batches (research notes, evidence from a meeting, raw source material). Has a template. Survives in git history.
+3. **`AGENTS.md`**: for rules and conventions you want the agent to follow every time. "We prefer functional components. Don't introduce new dependencies without flagging." Read at session start.
 
 For URLs or quick notes, the easiest path is to drop a file into `~/Downloads` and run:
 
@@ -82,7 +82,7 @@ construct doctor             # verify everything's healthy
 
 If you ran `construct init` and have Docker, you have three things running locally on Construct's reserved port block (`54329-54339`, chosen to avoid colliding with Next.js, Postgres, Redis, etc.):
 
-**Telemetry backend** (LLM observability — see your traces, costs, and quality scores)
+**Telemetry backend** (LLM observability: see your traces, costs, and quality scores)
 
 - URL: <http://localhost:54330>
 
@@ -97,7 +97,7 @@ If you ran `construct init` and have Docker, you have three things running local
 - Model auto-downloaded to `~/.construct/cache/embeddings/` on first use (~22 MB, one time)
 - Run `construct search "your query"` to see it work
 
-If you skipped Docker, Construct falls back to a local JSON vector index at `~/.construct/vector/index.json` and stops emitting traces — semantic search still works, just slower at scale, and the telemetry backend isn't available.
+If you skipped Docker, Construct falls back to a local JSON vector index at `~/.construct/vector/index.json` and stops emitting traces: semantic search still works, just slower at scale, and the telemetry backend isn't available.
 
 All ports bind to `127.0.0.1` only; nothing is reachable from other machines on your network.
 
@@ -115,7 +115,7 @@ All ports bind to `127.0.0.1` only; nothing is reachable from other machines on
 | `construct graph from-intake <id>` | Generate a task graph from a triaged intake packet |
 | `construct drop` | Ingest the most recent downloaded file |
 | `construct search "..."` | Hybrid file + SQL + semantic search over project state |
-| `construct uninstall` | Interactive teardown — never touches Docker or your code |
+| `construct uninstall` | Interactive teardown: never touches Docker or your code |
 
 Full reference: <https://geraldmaron.github.io/construct/v2/docs/reference/cli>
 
@@ -140,7 +140,7 @@ Troubleshooting guide: <https://geraldmaron.github.io/construct/v2/docs/operatio
 
 - [Connect your editor](https://geraldmaron.github.io/construct/v2/docs/start/connect-your-editor) if you haven't already.
 - [Run your first task](https://geraldmaron.github.io/construct/v2/docs/start/first-task) to feel the flow.
-- Skim [the architecture](https://geraldmaron.github.io/construct/v2/docs/concepts/architecture) when you have 10 minutes — it'll save you hours later.
+- Skim [the architecture](https://geraldmaron.github.io/construct/v2/docs/concepts/architecture) when you have 10 minutes: it'll save you hours later.
 
 If you'd rather have a teammate walk you through it, the persona itself can:
 

package/templates/docs/meta-prd.md

@@ -27,8 +27,8 @@ the org decides, documents, or evaluates work once this ships.
 <!--
 The current state of the operating system: which workflow, template, eval
 loop, or governance process is in play today, and what's actually happening
-when teams or agents use it. Cite real examples — recent PRDs, prior decisions,
-trace evidence, support tickets — not hypotheticals.
+when teams or agents use it. Cite real examples: recent PRDs, prior decisions,
+trace evidence, support tickets: not hypotheticals.
 -->
 
 ## Problem
@@ -40,7 +40,7 @@ Examples of the right shape:
 - "PRDs ship without rejected alternatives, so reviewers re-litigate decisions
   three weeks in. Happens on ~40% of PRDs in the last quarter."
 - "Postmortems are written by the on-call who shipped the bug, so the action
-  items reflect their proposals — not independent review."
+  items reflect their proposals: not independent review."
 -->
 
 ## Goals
@@ -63,7 +63,7 @@ the doc enters review."
 | | Description |
 |---|---|
 | **In scope** | <which templates, workflows, agents, gates, or evals are touched> |
-| **Out of scope** | <related operating systems explicitly deferred — name the reason> |
+| **Out of scope** | <related operating systems explicitly deferred: name the reason> |
 | **Adjacent (deferred)** | <natural follow-up changes not in this Meta PRD> |
 
 ## Principles
@@ -74,7 +74,7 @@ principle should be testable enough to guide tradeoffs when phases conflict.
 
 ## Inputs and evidence
 <!--
-What evidence the system consumes — customer notes, interviews, traces, Jira
+What evidence the system consumes: customer notes, interviews, traces, Jira
 issues, PRDs, research, analytics, support tickets, prior decisions. State
 minimum evidence thresholds where useful (e.g. "two independent customer
 interviews before a PRD enters review").
@@ -98,53 +98,53 @@ constraints, anti-patterns, rubric dimensions, pass/fail checks.
 Status values: not started | in progress | shipped | deferred.
 -->
 
-### Phase 1 — <name>
+### Phase 1: <name>
 
 - **Goal**: <what this phase delivers>
 - **Status**: not started
 
 **Workflow**
 
-- **MR-1.1** — <imperative statement of how the workflow must behave>
+- **MR-1.1**: <imperative statement of how the workflow must behave>
   - *Acceptance*: <how a reviewer or trace verifies this without asking the author>
-- **MR-1.2** — <...>
+- **MR-1.2**: <...>
   - *Acceptance*: <...>
 
 **Document + evaluation**
 
-- **DR-1.1** — <required section, evidence rule, citation rule, formatting constraint, or anti-pattern>
+- **DR-1.1**: <required section, evidence rule, citation rule, formatting constraint, or anti-pattern>
   - *Acceptance*: <rubric dimension, pass/fail check, or trace signal that proves it>
 
-### Phase 2 — <name>
+### Phase 2: <name>
 
 - **Goal**: <what this phase delivers>
 - **Status**: not started
 
 **Workflow**
 
-- **MR-2.1** — <...>
+- **MR-2.1**: <...>
   - *Acceptance*: <...>
-- **MR-2.2** — <...>
+- **MR-2.2**: <...>
   - *Acceptance*: <...>
 
 **Document + evaluation**
 
-- **DR-2.1** — <...>
+- **DR-2.1**: <...>
   - *Acceptance*: <...>
 
-### Phase 3 — <name>
+### Phase 3: <name>
 
 - **Goal**: <what this phase delivers>
 - **Status**: not started
 
 **Workflow**
 
-- **MR-3.1** — <...>
+- **MR-3.1**: <...>
   - *Acceptance*: <...>
 
 **Document + evaluation**
 
-- **DR-3.1** — <...>
+- **DR-3.1**: <...>
   - *Acceptance*: <...>
 
 ## Human approval gates

package/templates/docs/one-pager.md

@@ -12,7 +12,7 @@
 <!-- One paragraph. What we will do, at a level a non-specialist can understand. -->
 
 ## Why now
-<!-- One paragraph. What makes this the right moment — a trigger, a constraint, a window. -->
+<!-- One paragraph. What makes this the right moment: a trigger, a constraint, a window. -->
 
 ## Success measure
 <!-- The single metric that tells us this worked. Numeric, time-bound. -->

package/templates/docs/prd-business.md

@@ -22,7 +22,7 @@ Use prd-platform.md for internal platform and developer-facing capabilities.
 <!-- The one-paragraph view of market shape, buyer behavior, and where value accrues. Every decision in this document links back here or challenges it. -->
 
 ## Problem and opportunity
-<!-- What is broken in the market or business today? What does the opportunity look like at full scale? State the pain and the size of the prize — with evidence. -->
+<!-- What is broken in the market or business today? What does the opportunity look like at full scale? State the pain and the size of the prize: with evidence. -->
 
 ## Strategic goals
 <!-- What this decision achieves at the business level: position, revenue, defensibility, optionality. Tie to company objectives. -->

package/templates/docs/prd-platform.md

@@ -6,7 +6,7 @@
 
 <!--
 Use this for capabilities consumed by internal systems, developers, operators, or other
-services — not directly by end users. Covers APIs, SDKs, admin surfaces, data contracts,
+services: not directly by end users. Covers APIs, SDKs, admin surfaces, data contracts,
 shared infrastructure, and operational tooling.
 
 Use prd.md instead for customer-facing product capabilities.