@cubis/foundry 0.3.81 → 0.3.83

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/svelte-sveltekit/SKILL.md

@@ -79,8 +79,12 @@ Load detailed guidance based on context:
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/swift-best-practices/SKILL.md

@@ -80,8 +80,12 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/system-design/SKILL.md

@@ -75,8 +75,12 @@ Load only what the current task requires.
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/systematic-debugging/SKILL.md

@@ -110,8 +110,12 @@ Provide a disciplined, evidence-based framework for diagnosing and resolving sof
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/t3-stack/SKILL.md

@@ -71,8 +71,12 @@ Provide implementation code, schema definitions, configuration snippets, and arc
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/tech-doc/SKILL.md

@@ -74,8 +74,12 @@ Load on demand. Do not preload all reference files.
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/typescript-best-practices/SKILL.md

@@ -76,8 +76,12 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/unit-testing/SKILL.md

@@ -93,8 +93,12 @@ Provide a rigorous, repeatable methodology for designing, writing, and maintaini
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/vibesec/SKILL.md

@@ -89,8 +89,12 @@ Deliver a fast, opinionated security assessment that catches the most common and
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/vuejs/SKILL.md

@@ -80,8 +80,12 @@ Load detailed guidance based on context:
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

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 `PRODUCT.md`, `ENGINEERING_RULES.md`, `ARCHITECTURE.md`, and `TECH.md` in that order when they exist before planning or implementing.
+> **Rule:** For non-trivial work, read `docs/foundation/MEMORY.md` first when it exists. Then load `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, `docs/foundation/TECH.md`, `docs/foundation/memory/*.md`, and ADRs only as needed. Use the MEMORY load map to decide which deeper docs the active workflow, agent, or skill should consult.
 
 ---
 

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/antigravity.md

@@ -2,9 +2,8 @@
 
 ## Platform Paths
 
-- Workflows: `.agent/workflows`
-- Agents: `.agent/agents`
-- Skills: `.agent/skills`
+- Rules: `.agents/rules/GEMINI.md`
+- Skills: `.agents/skills/<skill-id>/SKILL.md`
 - Gemini commands: `.gemini/commands/*.toml`
 - Rules file: `GEMINI.md`
 
@@ -13,7 +12,7 @@
 Gemini recognizes these additional entry points:
 
 1. **Explicit Gemini command** (`.gemini/commands/*.toml`) — highest priority route.
-2. **Agent Manager** for multi-agent coordination — Gemini's orchestration surface.
+2. Foundry compiles `/workflow` and `@agent` routes into command entry points instead of installing undocumented workspace workflow or agent folders.
 3. Standard workflow/agent routing from shared steering.
 
 ## Gemini Commands
@@ -25,7 +24,7 @@ Gemini recognizes these additional entry points:
 ## Agent Manager
 
 - Gemini's Agent Manager handles multi-specialist coordination (equivalent to `@orchestrator`).
-- Agent Manager delegates to specialist agents defined in `.agent/agents/`.
+- In Foundry, specialist routes are exposed through generated command files rather than project-local agent markdown.
 - Use Agent Manager when work crosses 2+ domains with explicit handoff needs.
 
 ## Platform Notes

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/codex.md

@@ -2,16 +2,17 @@
 
 ## Platform Paths
 
-- Workflows: `.agents/workflows`
-- Agents: `.agents/agents`
-- Skills: `.agents/skills`
+- Workflow skills: `.agents/skills/<workflow-id>/SKILL.md`
+- Skills: `.agents/skills/<skill-id>/SKILL.md`
+- Native subagents: `.codex/agents/*.toml`
 - Rules file: `AGENTS.md`
 
 ## Platform-Specific Routing
 
 1. **Explicit `/workflow` or `@agent`** — highest priority route.
-2. Compatibility aliases (`$workflow-*`, `$agent-*`) may be accepted as hints but are never the primary route surface.
-3. Standard workflow/agent routing from shared steering.
+2. `/workflow` resolves to a native workflow skill in `.agents/skills/<workflow-id>/SKILL.md`.
+3. `@agent` resolves to a native Codex subagent in `.codex/agents/*.toml`.
+4. Standard workflow/agent routing from shared steering.
 
 ## Sandbox Constraints
 
@@ -25,5 +26,5 @@
 
 - Codex supports three autonomy levels: `suggest` (propose only), `auto-edit` (edit with confirmation), `full-auto` (autonomous execution).
 - Codex operates in a sandboxed environment — destructive operations are inherently limited.
-- Orchestration in Codex is capability-based: use native delegation when available, otherwise coordinate specialist postures sequentially.
+- Orchestration in Codex is native-subagent-first: delegate through `.codex/agents/*.toml` when the task benefits from a specialist handoff.
 - Keep workflow instructions self-contained since network access for external docs may be restricted.

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/copilot.md

@@ -2,7 +2,6 @@
 
 ## Platform Paths
 
-- Workflows: `.github/copilot/workflows`
 - Agents: `.github/agents`
 - Skills: `.github/skills`
 - Rules file: `copilot-instructions.md`
@@ -13,7 +12,7 @@
 ## Platform-Specific Routing
 
 1. **Explicit workflow prompt or `@agent`** — highest priority route.
-2. Copilot prompt files (`.github/prompts/*.prompt.md`) provide structured entry points.
+2. `/workflow` routes compile into prompt files (`.github/prompts/*.prompt.md`).
 3. Standard workflow/agent routing from shared steering.
 
 ## Agent Handoffs

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/gemini.md

@@ -2,15 +2,13 @@
 
 ## Platform Paths
 
-- Workflows: `.gemini/workflows`
-- Skills: `.gemini/skills`
 - Commands: `.gemini/commands`
 - Rules file: `.gemini/GEMINI.md` (or `GEMINI.md` at repo root when used directly)
 
 ## Platform-Specific Routing
 
 1. **Explicit Gemini command** (`.gemini/commands/*.toml`) — highest priority route.
-2. **Explicit workflow or named skill** — honor it directly before route discovery.
+2. Foundry compiles both `/workflow` and `@agent` routes into command entry points when targeting Gemini CLI.
 3. Standard workflow and MCP routing from shared steering.
 
 ## Platform Notes

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

@@ -1,6 +1,6 @@
 ---
 command: "/architecture"
-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."
+description: "Refresh the core project foundation docs in docs/foundation/MEMORY.md, docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, docs/foundation/memory/*.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance."
 triggers:
   [
     "architecture",
@@ -37,28 +37,54 @@ Use this when the task is to declare, refresh, or validate the project backbone
 
 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. Make `docs/foundation/ARCHITECTURE.md` explicitly state the architecture type in use and include a folder-structure guide for the important apps/packages/directories.
-6. Add or refresh Mermaid diagrams and flow narratives inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior.
-7. 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.
-8. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared structure or product constraints.
+3. Read `docs/foundation/MEMORY.md` first if it exists, then load `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `docs/foundation/TECH.md`, `docs/foundation/memory/*.md`, and ADRs on demand.
+4. Update the managed foundation sections in `docs/foundation/MEMORY.md`, `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `docs/foundation/TECH.md`, and `docs/foundation/memory/*.md`.
+5. Make `docs/foundation/MEMORY.md` the durable entrypoint: concise project summary, load-on-demand map, exact links to deeper docs, explicit consumer guidance for rules, workflows, agents, and skills, and a strong bias against bloat.
+6. Ensure each deeper foundation doc makes it obvious when it should be consulted and by which route families (planning/spec, architecture/refactor, build/test/debug, runtime/integration, or ADR work).
+7. Make `docs/foundation/ARCHITECTURE.md` explicitly state the architecture type in use and include a folder-structure guide for the important apps/packages/directories.
+8. Add or refresh Mermaid diagrams using fenced ` ```mermaid ` blocks with valid syntax inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior. Use `sequenceDiagram` for runtime flows and `graph TD` or `C4Context` for structural views.
+9. Ensure `docs/foundation/PRODUCT.md` includes a `## Domain Glossary` defining project-specific terms so future agents use consistent vocabulary.
+10. Ensure `docs/foundation/ARCHITECTURE.md` includes `## Crosscutting Concerns` (logging, auth, error handling patterns), `## Quality Requirements`, and `## Risks And Tech Debt` sections.
+11. Ensure `docs/foundation/TECH.md` includes `## Build And Validation` (exact commands from clean clone to passing CI), `## CI CD Pipeline` (workflow files and triggers), and `## Error Patterns And Debugging` (common errors and resolutions).
+12. Ensure the topic docs under `docs/foundation/memory/` stay narrow and task-oriented:
+    - `domain.md`
+    - `runtime.md`
+    - `integrations.md`
+    - `debugging.md`
+13. 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.
+14. 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`.
-- `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.
+- `docs/foundation/MEMORY.md` is the first-stop index for AI agents. It should stay concise, durable, and link outward instead of duplicating every deep detail.
+- Keep `docs/foundation/MEMORY.md` under roughly 120 lines when possible. If a section grows beyond a short paragraph or 5-7 bullets, move the detail into a deeper doc and leave only the routing summary behind.
+- `docs/foundation/PRODUCT.md` captures intent and domain glossary, `docs/foundation/ARCHITECTURE.md` captures accepted structure and crosscutting concerns, and `docs/foundation/TECH.md` is the developer-facing technical map with build/validation commands. Keep them aligned but not redundant.
+- `docs/foundation/MEMORY.md` should tell future rules, workflows, agents, and skills which deeper doc to consult for planning/spec work, architecture/refactors, build/test/debug work, runtime/integration work, and ADR-worthy decisions.
+- `docs/foundation/PRODUCT.md` should make it obvious that planning/spec/product routes consult it first; `docs/foundation/ARCHITECTURE.md` should make it obvious that architecture/refactor routes consult it first; `docs/foundation/TECH.md` should make it obvious that build/test/debug/devops routes consult it first.
+- Favor a lean arc42/C4 style: clear scope, boundaries, building blocks, runtime flows, crosscutting concerns, quality requirements, risks, deployment/testing notes, and only diagrams that add real value.
 - `docs/foundation/ARCHITECTURE.md` should guide future contributors, not just describe the system. Be explicit about architecture style and folder ownership.
+- `docs/foundation/TECH.md` should enable an AI agent to start working immediately: exact build commands, environment setup, error patterns, and validation steps.
+- Topic docs in `docs/foundation/memory/` should be load-on-demand references rather than duplicated summary docs, and should clearly indicate which runtime, integration, or debugging routes benefit from them.
 - Prefer stable section headings over ad hoc prose so future refreshes stay clean and easy to diff.
+- All generated markdown must use correct formatting: single H1, proper heading hierarchy, fenced code blocks with language identifiers, valid Mermaid syntax, and tables with header/separator rows.
 - Preserve manual content outside the managed foundation sections.
 - Mark non-applicable sections explicitly instead of silently omitting them.
+- Use relative markdown links between foundation docs: `[ARCHITECTURE.md](docs/foundation/ARCHITECTURE.md)`.
 
 ## Verification
 
 - Managed foundation sections exist in the target docs under `docs/foundation/`.
+- `docs/foundation/MEMORY.md` exists and points cleanly to the deeper backbone docs and topic docs.
+- `docs/foundation/MEMORY.md` includes a clear consumer/load map for rules, workflows, agents, and skills.
+- `docs/foundation/MEMORY.md` stays lean and index-like instead of copying large sections from the deeper foundation docs.
 - Product intent, architecture style, dependency rules, and technical guidance are explicit.
+- `docs/foundation/PRODUCT.md` includes a `## Domain Glossary` with project-specific terms.
+- `docs/foundation/ARCHITECTURE.md` includes `## Crosscutting Concerns`, `## Quality Requirements`, and `## Risks And Tech Debt`.
 - `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.
+- `docs/foundation/TECH.md` includes `## Build And Validation` with exact commands and `## Error Patterns And Debugging`.
+- All Mermaid diagrams use fenced ```mermaid blocks with valid syntax (no rendering errors).
+- All markdown files use correct heading hierarchy (single H1, no skipped levels).
 - The update records `doc_impact` and whether future feature work must refresh the docs again.
 
 ## Output Contract
@@ -70,19 +96,32 @@ ARCHITECTURE_WORKFLOW_RESULT:
   primary_skills: [architecture-doc, system-design, tech-doc, frontend-design]
   supporting_skills: [api-design?, database-design?, sadd?, deep-research?]
   managed_targets:
+    memory_doc: docs/foundation/MEMORY.md
     product_doc: docs/foundation/PRODUCT.md
     architecture_doc: docs/foundation/ARCHITECTURE.md
     tech_doc: docs/foundation/TECH.md
+    memory_topics_dir: docs/foundation/memory
     adr_dir: docs/foundation/adr
-  files_updated: [docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md]
+  files_updated: [docs/foundation/MEMORY.md, docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, docs/foundation/memory/domain.md, docs/foundation/memory/runtime.md, docs/foundation/memory/integrations.md, docs/foundation/memory/debugging.md]
   architecture_contract:
     style: <string>
     dependency_rules: [<string>]
     design_system_source: <string>
+    crosscutting_concerns: [<string>]
+    quality_requirements: [<string>]
+    risks_and_tech_debt: [<string>]
   technical_snapshot:
     topology: [<string>]
     flows: [<string>]
     diagrams: [<string>] | []
+    build_commands: [<string>]
+    error_patterns: [<string>] | []
+  product_glossary: [<string>] | []
+  consumer_guidance:
+    memory_routes: [<string>]
+    product_routes: [<string>]
+    architecture_routes: [<string>]
+    tech_routes: [<string>]
   doc_impact: rules | tech | both
   next_actions: [<string>] | []
 ```

package/workflows/workflows/agent-environment-setup/shared/workflows/implement-track.md

@@ -21,7 +21,7 @@ Use this for large-scale implementation work that spans multiple sessions or mil
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the implementation plan, milestone definitions, and acceptance criteria per milestone.
 - Reuse `docs/specs/<spec-id>/` when present instead of maintaining a separate progress source of truth.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next before starting milestone execution.
+- Read `ENGINEERING_RULES.md` first and `docs/foundation/TECH.md` next before starting milestone execution. Use `## Build And Validation` for the validated build sequence and `## Key Commands` for test/lint commands.
 
 ## Skill Routing
 

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

@@ -28,7 +28,7 @@ Use this for technology migrations, framework upgrades, dependency updates, or m
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the migration target, current versions, breaking change lists, and impact assessment.
-- Read `ENGINEERING_RULES.md` and `TECH.md` first because migrations often change accepted patterns and current-state architecture at the same time.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` first because migrations often change accepted patterns and current-state architecture at the same time. After migration, flag updates needed in `docs/foundation/ARCHITECTURE.md` for `## Risks And Tech Debt`.
 
 ## Skill Routing
 

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

@@ -20,7 +20,7 @@ Use this for mobile app development, Flutter architecture, Stitch-driven mobile
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach platform targets (iOS, Android, both), Flutter version, and relevant screen/feature context.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before implementing non-trivial mobile work so screens and features follow the declared architecture and design-system rules.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` before implementing non-trivial mobile work so screens and features follow the declared architecture and design-system rules. Check `docs/foundation/PRODUCT.md` for `## Domain Glossary` to use consistent terminology.
 
 ## Skill Routing
 

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

@@ -27,7 +27,7 @@ Use this when joining a new project, exploring an unfamiliar codebase, or prepar
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Provide the repo URL, focus areas, and any specific questions to answer during onboarding.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next when present so onboarding distinguishes the intended contract from current implementation reality.
+- Read `ENGINEERING_RULES.md` first, then `docs/foundation/TECH.md`, `docs/foundation/PRODUCT.md`, and `docs/foundation/ARCHITECTURE.md` when present so onboarding distinguishes the intended contract from current implementation reality. Use the `## Domain Glossary` in PRODUCT.md to learn project-specific terms, and `## Build And Validation` in TECH.md to set up the local environment.
 
 ## Skill Routing
 

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

@@ -20,7 +20,7 @@ Use this when a task spans multiple domains (backend + frontend, security + infr
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the full task description, constraints, acceptance criteria, and relevant context when starting.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before decomposing non-trivial work, then reuse any existing `docs/specs/<spec-id>/` pack as the handoff source of truth.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` before decomposing non-trivial work. Check `docs/foundation/TECH.md` for build/validation commands and `docs/foundation/PRODUCT.md` for domain glossary. Then reuse any existing `docs/specs/<spec-id>/` pack as the handoff source of truth.
 
 ## Skill Routing
 

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

@@ -31,7 +31,7 @@ Use this when starting a new feature, project, or significant change that needs
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the feature request, problem statement, constraints, and any existing design documents.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next when they exist before finalizing a non-trivial plan.
+- Read `ENGINEERING_RULES.md` first and `docs/foundation/TECH.md` next when they exist before finalizing a non-trivial plan. Also check `docs/foundation/PRODUCT.md` for domain glossary and `docs/foundation/ARCHITECTURE.md` for crosscutting concerns and dependency rules.
 - Reuse an existing `docs/specs/<spec-id>/` pack when the change already has one instead of creating a parallel planning track.
 
 ## Skill Routing

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

@@ -20,7 +20,7 @@ Use this when improving code structure, reducing tech debt, or modularizing with
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the target code, pain points, and any constraints on what can change.
-- Read `ENGINEERING_RULES.md` and `TECH.md` first so behavior-preserving structure changes do not drift from the accepted architecture contract.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` first so behavior-preserving structure changes do not drift from the accepted architecture contract. Check `docs/foundation/ARCHITECTURE.md` for `## Dependency Rules` and `## Crosscutting Concerns` before restructuring.
 
 ## Skill Routing
 

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

@@ -20,7 +20,7 @@ Use this when preparing a release, deploying to production, or managing a rollou
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the release scope, version number, changelog draft, and deployment target.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before release if the shipped changes touched architecture, scaling assumptions, or design-system rules.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` before release if the shipped changes touched architecture, scaling assumptions, or design-system rules. Check `docs/foundation/TECH.md` for `## Build And Validation` and `## CI CD Pipeline` steps to verify the release pipeline.
 
 ## Skill Routing
 

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

@@ -38,7 +38,7 @@ 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 `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `ENGINEERING_RULES.md`, or `docs/foundation/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`. If the change adds new terms, update the `## Domain Glossary` in `docs/foundation/PRODUCT.md`. If the change introduces new crosscutting patterns or tech debt, flag updates needed in `docs/foundation/ARCHITECTURE.md`.
 5. Identify the next execution route and hand off without replanning the same work.
 
 ## Context notes

package/workflows/workflows/agent-environment-setup/platforms/antigravity/workflows/accessibility.md

@@ -1,77 +0,0 @@
----
-command: "/accessibility"
-description: "Run a structured accessibility audit on web UI code with WCAG 2.2 AA compliance checks, ARIA validation, keyboard navigation testing, and screen reader verification."
-triggers:
-  [
-    "accessibility",
-    "a11y",
-    "wcag",
-    "aria",
-    "screen reader",
-    "keyboard navigation",
-  ]
----
-
-# Accessibility Workflow
-
-## When to use
-
-Use this for accessibility audits, WCAG compliance review, or improving accessible user experience.
-
-## Routing
-
-- Primary specialist: `.agent/agents/frontend-specialist`
-- Verification support: `.agent/agents/test-engineer`
-- Review support: `.agent/agents/validator`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the target components, pages, or routes to audit. Include any existing axe or Lighthouse results.
-
-## Skill Routing
-
-- Primary skills: `code-review`, `frontend-design`
-- Supporting skills (optional): `frontend-design`, `performance-testing`, `react`, `nextjs`, `frontend-design`, `playwright-interactive`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `code-review` for WCAG compliance checks. Add `frontend-design` for accessible design patterns. Add `frontend-design` for RTL and locale-specific accessibility.
-
-## Workflow steps
-
-1. Inventory components and user flows to audit.
-2. Run automated accessibility checks (axe, Lighthouse).
-3. Manual keyboard navigation and focus management review.
-4. ARIA validation — correct roles, states, and properties.
-5. Screen reader compatibility assessment.
-6. Prioritize findings and provide remediation guidance.
-
-## Verification
-
-- All critical WCAG 2.2 AA violations identified.
-- Keyboard navigation works for all interactive elements.
-- ARIA attributes are semantically correct.
-- Color contrast meets minimum ratios.
-- Focus management is logical and visible.
-
-## Output Contract
-
-```yaml
-ACCESSIBILITY_WORKFLOW_RESULT:
-  primary_agent: frontend-specialist
-  supporting_agents: [test-engineer?, validator?]
-  primary_skills: [code-review, frontend-design]
-  supporting_skills: [frontend-design?, performance-testing?, playwright-interactive?]
-  audit_scope: [<component-or-route>]
-  findings:
-    - severity: critical | high | medium | low
-      wcag_criterion: <string>
-      element: <string>
-      description: <string>
-      remediation: <string>
-  automated_results:
-    tool: <axe | lighthouse | other>
-    violations: <number>
-    passes: <number>
-  follow_up_items: [<string>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.