@geraldmaron/construct 1.0.17 → 1.0.18

package/commands/design/flow.md

@@ -8,3 +8,5 @@ Produce:
 - JOBS-TO-BE-DONE: "When [situation], I want to [motivation], so I can [outcome]."
 - FRICTION MAP: 5 likely points where users get stuck, confused, or quit
 - DESIGN-DRIVING QUESTIONS: a small set of questions (typically 3-7) whose answers would change layout, flow, or interaction decisions
+
+To capture the flow as a committed artifact, run `construct wireframe "<flow description>" --type=flow` (or `--type=user-journey` for a persona funnel) to emit a diffable Mermaid diagram under `.cx/wireframes/`. Stay text-first (no new diagramming dependency).

package/commands/design/ui.md

@@ -10,3 +10,5 @@ Every meaningful UI surface needs:
 - WCAG AA baseline: keyboard-navigable, 4.5:1 contrast, visible focus, ARIA labels
 
 Does it look intentional, or like a default template? Flag experience drift.
+
+For a layout sketch, run `construct wireframe "<screen description>" --type=layout` to produce a committed low-fi HTML/Mermaid artifact under `.cx/wireframes/`, then refine it. Stay text-first (no new diagramming dependency). Valid `--type` values: layout, flow, state, sequence, er, user-journey.

package/lib/embed/semantic.mjs

@@ -1,7 +1,7 @@
 /**
  * lib/embed/semantic.mjs — Semantic analysis for intake signals.
  *
- * Generates embeddings via @xenova/transformers, caches them to disk,
+ * Generates embeddings via @huggingface/transformers, caches them to disk,
  * computes cosine similarity, and clusters related signals by topic.
  * All local — no external API calls. Default model is all-MiniLM-L6-v2
  * (384-dimensional vectors, ~50MB on disk, fast inference).
@@ -23,7 +23,7 @@ import { homedir } from 'node:os';
 
 const CACHE_DIR = join(homedir(), '.cx', 'cache', 'embeddings');
 const INDEX_FILE = join(CACHE_DIR, 'index.json');
-const MODEL_NAME = 'all-MiniLM-L6-v2';
+const MODEL_NAME = 'Xenova/all-MiniLM-L6-v2';
 const DIMENSIONS = 384;
 const LOG = process.env.CONSTRUCT_DEBUG_EMBED === '1';
 
@@ -35,7 +35,9 @@ let embedder = null;
 async function getEmbedder() {
   if (embedder !== null) return embedder;
   try {
-    const { pipeline } = await import('@xenova/transformers');
+    const { pipeline, env: hfEnv } = await import('@huggingface/transformers');
+    hfEnv.allowLocalModels = true;
+    hfEnv.useBrowserCache = false;
     embedder = await pipeline('feature-extraction', MODEL_NAME, {
       quantized: true,
     });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@geraldmaron/construct",
-  "version": "1.0.17",
+  "version": "1.0.18",
   "type": "module",
   "description": "Construct — agent orchestration layer for OpenCode, Claude Code, and other coding surfaces",
   "bin": {
@@ -69,20 +69,20 @@
     "eval:routing": "node scripts/eval/score-intent-classifier.mjs",
     "release:check": "node ./bin/construct doctor && npm test && node ./bin/construct docs:update --check && node ./bin/construct dashboard:sync --check && node ./bin/construct lint:comments && node scripts/lint-commits-pr.mjs",
     "release:gate": "node --test tests/functional/release-gate.functional.test.mjs",
+    "audit:published": "node scripts/audit-published-artifact.mjs",
     "release:preflight": "node scripts/pre-release-check.mjs",
     "release:preflight:no-auth": "node scripts/pre-release-check.mjs --skip-auth",
     "npm:publish": "npm run release:check && npm publish --access public",
     "postinstall": "node ./bin/construct-postinstall.mjs"
   },
   "dependencies": {
-    "@huggingface/transformers": "^4.2.0",
     "@modelcontextprotocol/sdk": "^1.12.0",
-    "@xenova/transformers": "^2.0.1",
     "js-yaml": "^4.2.0",
     "node-webvtt": "^1.9.3",
     "postgres": "^3.4.9"
   },
   "optionalDependencies": {
+    "@huggingface/transformers": "^4.2.0",
     "@opentelemetry/api": "^1.9.0",
     "@opentelemetry/core": "^2.7.1",
     "@opentelemetry/exporter-trace-otlp-http": "^0.218.0",
@@ -91,7 +91,6 @@
     "@opentelemetry/semantic-conventions": "^1.25.0"
   },
   "overrides": {
-    "express-rate-limit": "8.5.1",
-    "protobufjs": "^8.4.2"
+    "express-rate-limit": "8.5.1"
   }
 }

package/specialists/prompts/cx-architect.md

@@ -16,6 +16,7 @@ You have inherited enough unmaintainable systems to be permanently suspicious of
 **Failure mode warning**: If the ADR has no "options rejected" section, the decision wasn't made: it defaulted. Defaulted decisions are the ones that bite hardest.
 
 **Role guidance**: call `get_skill("roles/architect")` before drafting.
+**Templates**: call `get_template("adr")` before authoring an ADR so the section structure, framing rules, and rejected-alternatives requirement come from the canonical template rather than memory. Use `list_templates` to discover overrides.
 **Strategy grounding**: for decisions with long-term interface or data model implications, check `.cx/knowledge/decisions/strategy/` for any declared strategy documents before choosing. A decision that contradicts a declared Bet or enables a Non-bet must surface the conflict explicitly in the ADR's OPTIONS CONSIDERED section. If no strategy documents exist, proceed without: do not block the workflow or invent strategy.
 
 When the architecture domain is clear, also load exactly one relevant overlay before drafting:

package/specialists/prompts/cx-designer.md

@@ -32,7 +32,7 @@ When the user asks for a visual deliverable, choose the lightest artifact that h
 - walkthroughs and demo videos: use the available browser/demo tooling and follow a discover → rehearse → record flow instead of jumping straight to recording
 
 Tool and skill discipline:
-- prefer existing visual tools such as `construct wireframe` or equivalent Mermaid/HTML outputs before inventing bespoke formats
+- prefer the bundled generator before inventing bespoke formats: `construct wireframe "<description>" --type=<layout|flow|state|sequence|er|user-journey>` writes a diffable artifact to `.cx/wireframes/`. Use `layout` for screens, `flow`/`user-journey` for paths, `state`/`sequence`/`er` for system diagrams. It is zero-dependency and text-first; do not add a diagramming library
 - use `list_skills` and `search_skills` to load the host's relevant visual skill when the ask is a deck, presentation, polished UI exploration, or demo video
 - if the user provides source material like a `.pptx`, export, or PDF, ingest it first so the deliverable is grounded in the actual content
 

package/specialists/prompts/cx-operations.md

@@ -16,6 +16,7 @@ A beautiful plan is worthless if it can't be executed in the right sequence. You
 **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.
+**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-rd-lead.md

@@ -16,6 +16,7 @@ Most "problems" that arrive on your desk are actually hypotheses masquerading as
 **Failure mode warning**: If you can't write a falsifiable hypothesis, you don't have an R&D task: you have a planning task being treated as R&D to avoid committing to a spec.
 
 **Role guidance**: call `get_skill("roles/architect")` before drafting.
+**Templates**: call `get_template("research-brief")` before authoring so the section structure comes from the canonical template rather than memory. Use `list_templates` to discover overrides.
 **Evidence policy**: hypotheses must be grounded in evidence, not plausibility. Follow `rules/common/research.md` (most-recent-first, primary sources, verified URLs) when citing external literature, benchmarks, or published results to motivate an R&D task.
 **Strategy grounding**: before proposing an R&D direction, check `.cx/knowledge/decisions/strategy/` for declared Bets and Non-bets. A research direction that contradicts a Non-bet requires explicit surfacing and user decision before proceeding.
 

package/specialists/prompts/cx-sre.md

@@ -16,6 +16,7 @@ You have been paged at 2am enough times to know that reliability problems are de
 **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.
+**Templates**: call `get_template("runbook")` before authoring a runbook and `get_template("incident-report")` before authoring a 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/registry.json

@@ -271,7 +271,7 @@
       "modelTier": "standard",
       "reasoningEffort": "medium",
       "codexSandbox": "read-only",
-      "claudeTools": "Read,Grep,Glob,LS,WebSearch,WebFetch,list_skills,get_skill,search_skills,memory_search,memory_add_observations",
+      "claudeTools": "Read,Grep,Glob,LS,WebSearch,WebFetch,list_skills,get_skill,search_skills,get_template,list_templates,memory_search,memory_add_observations",
       "promptFile": "specialists/prompts/cx-researcher.md",
       "embedOrientation": {
         "focusAreas": [
@@ -1075,7 +1075,7 @@
       "modelTier": "standard",
       "reasoningEffort": "medium",
       "codexSandbox": "workspace-write",
-      "claudeTools": "Read,Grep,Glob,LS,Edit,Write,Bash,list_skills,get_skill,search_skills,memory_search,memory_add_observations",
+      "claudeTools": "Read,Grep,Glob,LS,Edit,Write,Bash,list_skills,get_skill,search_skills,get_template,list_templates,memory_search,memory_add_observations",
       "promptFile": "specialists/prompts/cx-docs-keeper.md",
       "embedOrientation": {
         "focusAreas": [

package/templates/docs/test-plan.md

@@ -0,0 +1,96 @@
+# Test Plan: {feature or system name}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name or role}
+- **Status**: draft | in-review | approved | executed
+- **Related**: {PRD / ADR paths or none}
+
+<!--
+Use this when a feature, migration, or system change needs a deliberate
+verification strategy before it ships. The plan is the contract between
+what was specified and what will be proven; every scenario below must
+trace to a requirement or an observed risk, never to guesswork.
+
+Before drafting, read rules/common/framing.md and rules/common/no-fabrication.md.
+Acceptance criteria must be binary pass/fail. If a criterion cannot be
+checked without asking the author, it is not done. Cite the requirement
+(FR/NFR id, ADR decision, ticket) each scenario verifies.
+-->
+
+## Scope
+<!--
+What is under test and what is explicitly not. Name the components, surfaces,
+or behaviors covered. The out-of-scope list protects reviewer attention and
+makes coverage gaps deliberate rather than accidental.
+-->
+
+| | Description |
+|---|---|
+| **In scope** | <what this plan verifies> |
+| **Out of scope** | <related behavior deliberately not tested here, and why> |
+
+## Test strategy
+<!--
+The levels of testing applied and why each is justified. Map levels to risk:
+unit for logic, integration for contracts and boundaries, end-to-end for
+user-visible flows, manual/exploratory for what automation cannot reach.
+State what each level is responsible for so coverage gaps are visible.
+-->
+
+| Level | What it covers | Why it lives at this level |
+|---|---|---|
+| Unit | <logic, pure functions, edge cases> | <reason> |
+| Integration | <contracts, boundaries, data access> | <reason> |
+| End-to-end | <user-visible flows> | <reason> |
+| Manual / exploratory | <what automation cannot reach> | <reason> |
+
+## Key scenarios
+<!--
+The scenarios that prove the change works. Each scenario names the requirement
+it verifies, the setup, the action, and the binary acceptance criterion. A
+reviewer must be able to run or read the scenario and decide pass/fail without
+asking the author.
+-->
+
+| ID | Scenario | Verifies | Acceptance (binary pass/fail) |
+|---|---|---|---|
+| TC-1 | <setup, action, expected result> | <FR/NFR id or risk> | <observable condition> |
+| TC-2 | <...> | <...> | <...> |
+
+## Risks and edge cases
+<!--
+The failure modes and boundary conditions worth explicit attention: empty
+inputs, concurrency, partial failure, large data, permission boundaries,
+rollback. For each, state how the plan covers it or why the residual risk
+is accepted.
+-->
+
+| Risk / edge case | Likelihood | Impact | Coverage or accepted reason |
+|---|---|---|---|
+| <condition> | low / med / high | low / med / high | <how it is tested, or why accepted> |
+
+## Environments and data
+<!--
+Where tests run and what data they use. Name the environments, fixtures,
+seed data, and any external dependencies (sandboxes, stubs, recorded
+responses). Flag data that must be synthetic or anonymized.
+-->
+
+## Entry and exit criteria
+<!--
+Entry: what must be true before testing starts (build available, environment
+provisioned, dependencies stubbed). Exit: what must be true to call testing
+done (all blocking scenarios pass, known issues triaged, coverage threshold
+met). Both are checklists a reviewer can verify.
+-->
+
+**Entry criteria**
+
+- <condition that must hold before execution begins>
+
+**Exit criteria**
+
+- <condition that must hold to declare the plan executed>
+
+## References
+<!-- PRD, ADR, RFC, related test plans, prior incidents. -->