@cubis/foundry 0.3.78 → 0.3.80

package/workflows/workflows/agent-environment-setup/platforms/gemini/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 `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `ENGINEERING_RULES.md`, or `docs/foundation/TECH.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 `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/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.
 

package/workflows/workflows/agent-environment-setup/shared/rules/STEERING.md

@@ -37,7 +37,7 @@ Follow this decision tree for EVERY user request:
 
 > **Rule:** Inspect the repo and task locally BEFORE choosing a route or loading any skill.
 > **Rule:** If the user already chose the route, do not re-route it unless the named workflow, agent, or skill is invalid.
-> **Rule:** For non-trivial work, read `ENGINEERING_RULES.md` first and `TECH.md` next when they exist before planning or implementing.
+> **Rule:** For non-trivial work, read `PRODUCT.md`, `ENGINEERING_RULES.md`, `ARCHITECTURE.md`, and `TECH.md` in that order when they exist before planning or implementing.
 
 ---
 
@@ -97,7 +97,7 @@ Research output contract:
 - **Gaps / unknowns** — what could not be verified.
 - **Recommended next route** — workflow, agent, or skill to use after research.
 
-When the research result shows a change to project structure, boundaries, design system, or testing strategy, surface `doc_impact` and recommend `/architecture` or a managed-doc refresh before or after implementation.
+When the research result shows a change to product direction, project structure, boundaries, design system, or testing strategy, surface `doc_impact` and recommend `/architecture` or a managed-doc refresh before or after implementation.
 
 ---
 
@@ -195,7 +195,7 @@ Use the best specialist first:
 4. State what was NOT validated.
 5. Use web search only when information may be stale, public comparison matters, or the user explicitly asks.
 6. Prefer official docs first. Treat Reddit/community sources as secondary evidence and label them that way.
-7. If the task changes project structure, scaling assumptions, or design-system rules, update or flag `ENGINEERING_RULES.md` and `TECH.md`.
+7. If the task changes product direction, project structure, scaling assumptions, or design-system rules, update or flag `PRODUCT.md`, `ARCHITECTURE.md`, `ENGINEERING_RULES.md`, `TECH.md`, and `ROADMAP.md` as needed.
 
 ---
 

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 core project foundation docs in docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, and ADR scaffolds with explicit structure, product context, 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,27 @@ 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 derive the current product surfaces, architecture style, module boundaries, technical constraints, and testing strategy from the codebase itself.
+2. Read concrete repo anchors before drafting: root README/manifests, main entrypoints, the primary app roots, existing `docs/specs/`, and representative source folders for each major surface.
+3. Read `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order if they exist.
+4. Update the managed foundation sections in `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md`.
+5. Add or refresh Mermaid diagrams and flow narratives inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior.
+6. Seed or refresh `docs/foundation/adr/README.md` and `docs/foundation/adr/0000-template.md`, and keep ADR linkage explicit when decisions should be durable.
+7. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared structure or product constraints.
 
 ## 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.
-- Preserve manual content outside the managed architecture sections.
+- `docs/foundation/PRODUCT.md` captures intent, `docs/foundation/ARCHITECTURE.md` captures accepted structure, and `docs/foundation/TECH.md` is the developer-facing technical map. Keep them aligned but not redundant.
+- Favor a lean arc42/C4 style: clear scope, boundaries, building blocks, runtime flows, deployment/testing notes, and only diagrams that add real value.
+- Preserve manual content outside the managed foundation 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 foundation sections exist in the target docs under `docs/foundation/`.
+- Product intent, architecture style, dependency rules, and technical guidance are explicit.
+- `docs/foundation/ARCHITECTURE.md` or `docs/foundation/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 +67,11 @@ ARCHITECTURE_WORKFLOW_RESULT:
   primary_skills: [architecture-doc, system-design, tech-doc, frontend-design]
   supporting_skills: [api-design?, database-design?, sadd?, deep-research?]
   managed_targets:
-    rules_doc: ENGINEERING_RULES.md
-    tech_doc: TECH.md
-  files_updated: [ENGINEERING_RULES.md, TECH.md]
+    product_doc: docs/foundation/PRODUCT.md
+    architecture_doc: docs/foundation/ARCHITECTURE.md
+    tech_doc: docs/foundation/TECH.md
+    adr_dir: docs/foundation/adr
+  files_updated: [docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.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 `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `ENGINEERING_RULES.md`, or `docs/foundation/TECH.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 `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/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.