@cubis/foundry 0.3.78 → 0.3.79

package/workflows/workflows/agent-environment-setup/shared/workflows/architecture.md

@@ -1,6 +1,6 @@
 ---
 command: "/architecture"
-description: "Refresh the project architecture contract and current-state map in ENGINEERING_RULES.md and TECH.md with explicit structure, design-system, testing, and flow guidance."
+description: "Refresh the project backbone docs in PRODUCT.md, ARCHITECTURE.md, ENGINEERING_RULES.md, TECH.md, ROADMAP.md, and ADR scaffolds with explicit structure, design-system, testing, and flow guidance."
 triggers:
   [
     "architecture",
@@ -18,7 +18,7 @@ triggers:
 
 ## When to use
 
-Use this when the task is to declare, refresh, or validate the project architecture contract and current-state map, especially after structure changes, scale changes, design-system changes, migrations, or major feature additions.
+Use this when the task is to declare, refresh, or validate the project backbone docs, especially after structure changes, scale changes, design-system changes, migrations, product-direction shifts, or major feature additions.
 
 ## Routing
 
@@ -35,24 +35,25 @@ Use this when the task is to declare, refresh, or validate the project architect
 
 ## Workflow steps
 
-1. Inspect the repo first and read `ENGINEERING_RULES.md` followed by `TECH.md` if they exist.
-2. Determine the current architecture style, module boundaries, design-system source of truth, and testing strategy from the codebase.
-3. Update only the managed architecture sections in `ENGINEERING_RULES.md` and `TECH.md`.
-4. Add or refresh Mermaid diagrams and flow narratives inside `TECH.md` when they clarify system behavior.
-5. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared rules.
+1. Inspect the repo first and read `PRODUCT.md`, `ENGINEERING_RULES.md`, `ARCHITECTURE.md`, and `TECH.md` in that order if they exist.
+2. Determine the current product surfaces, architecture style, module boundaries, design-system source of truth, roadmap themes, and testing strategy from the codebase.
+3. Update the managed backbone sections in `PRODUCT.md`, `ARCHITECTURE.md`, `ENGINEERING_RULES.md`, `TECH.md`, and `ROADMAP.md`.
+4. Add or refresh Mermaid diagrams and flow narratives inside `ARCHITECTURE.md` or `TECH.md` when they clarify system behavior.
+5. Seed or refresh `docs/adr/README.md` and keep ADR linkage explicit when decisions should be durable.
+6. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared rules.
 
 ## Context notes
 
 - This workflow is route-fixed and skill-fixed: do not start with `route_resolve` or `skill_search`.
-- `ENGINEERING_RULES.md` is normative. `TECH.md` is descriptive. Keep them aligned but not redundant.
+- `PRODUCT.md` captures intent, `ARCHITECTURE.md` captures accepted structure, `ENGINEERING_RULES.md` is normative, and `TECH.md` is descriptive. Keep them aligned but not redundant.
 - Preserve manual content outside the managed architecture sections.
 - Mark non-applicable sections explicitly instead of silently omitting them.
 
 ## Verification
 
-- Managed architecture sections exist in both target docs.
-- Architecture style, dependency rules, and design-system guidance are explicit.
-- `TECH.md` includes flow text and at least one Mermaid diagram when the repo has meaningful flow complexity.
+- Managed backbone sections exist in the target docs.
+- Product intent, architecture style, dependency rules, and design-system guidance are explicit.
+- `ARCHITECTURE.md` or `TECH.md` includes flow text and at least one Mermaid diagram when the repo has meaningful flow complexity.
 - The update records `doc_impact` and whether future feature work must refresh the docs again.
 
 ## Output Contract
@@ -64,9 +65,13 @@ ARCHITECTURE_WORKFLOW_RESULT:
   primary_skills: [architecture-doc, system-design, tech-doc, frontend-design]
   supporting_skills: [api-design?, database-design?, sadd?, deep-research?]
   managed_targets:
+    product_doc: PRODUCT.md
+    architecture_doc: ARCHITECTURE.md
     rules_doc: ENGINEERING_RULES.md
     tech_doc: TECH.md
-  files_updated: [ENGINEERING_RULES.md, TECH.md]
+    roadmap_doc: ROADMAP.md
+    adr_dir: docs/adr
+  files_updated: [PRODUCT.md, ARCHITECTURE.md, ENGINEERING_RULES.md, TECH.md, ROADMAP.md]
   architecture_contract:
     style: <string>
     dependency_rules: [<string>]

package/workflows/workflows/agent-environment-setup/shared/workflows/spec.md

@@ -38,12 +38,12 @@ Use this for non-trivial work that needs durable planning in Git before implemen
 1. Determine whether the task is non-trivial enough to justify a spec pack.
 2. Find an existing `docs/specs/<spec-id>/` pack or create a new stable `spec_id`.
 3. Write or refresh the spec pack with brief, acceptance, tasks, traceability, and handoff files.
-4. Record `architecture_impact`, `doc_impact`, and any required updates to `ENGINEERING_RULES.md` or `TECH.md`.
+4. Record `architecture_impact`, `doc_impact`, and any required updates to `PRODUCT.md`, `ARCHITECTURE.md`, `ENGINEERING_RULES.md`, `TECH.md`, or `ROADMAP.md`.
 5. Identify the next execution route and hand off without replanning the same work.
 
 ## Context notes
 
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next when they exist because they define the accepted architecture contract and current state.
+- Read `PRODUCT.md`, `ENGINEERING_RULES.md`, `ARCHITECTURE.md`, and `TECH.md` in that order when they exist because they define the accepted product direction, architecture contract, and current state.
 - Prefer repo evidence first; escalate to `deep-research` only when freshness, public comparison, or explicit research requests require it.
 - Keep spec packs lean. Trivial one-step tasks should stay on the lightweight path with no new spec directory.