@warpgogol/forge 0.3.1

package/skills/fo/fo-harvest/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: fo-harvest
+description: Systematic self-growth loop — scan the whole project for forge-worthy patterns, grill the operator on portability, and port accepted candidates via port-to-forge / forge.port.scaffold.
+category: fo
+invocation: user
+concerns: code-mutation
+dependsOn:
+  - my-preferences
+  - grilling
+languagePolicy: ref(PREFERENCES.md)
+triggers: ["harvest portable patterns from code", "extract reusable code pattern to forge", "port this pattern to forge"]
+---
+
+# fo-harvest
+
+The systematic self-growth loop for forge. Discover patterns proven in real project work that deserve to be canonicalized into `packages/forge`, grill the operator on portability per candidate, and port accepted candidates through the existing `port-to-forge` skill and `forge.port.scaffold` command.
+
+## When to invoke
+
+- After completing a significant feature, refactor, or bug fix session — the operator wants to check if any patterns emerged that belong in forge.
+- When the operator suspects project-local conventions have matured enough to become portable.
+- As a periodic sweep (operator-invoked, never automatic).
+
+## Process
+
+### 1. Read preferences
+
+Read `PREFERENCES.md` at the repository root. Use `aiLanguage` for all communication.
+
+### 2. Full project scan
+
+Scan the project for harvest candidates:
+
+- `.agents/skills/` — skills that were created or significantly modified during project work
+- Command modules — commands that could be generalized beyond the current project
+- `AGENTS.md` deltas — new rules or conventions that other projects could benefit from
+- Recurring code patterns — abstractions, utilities, or patterns that appear in 2+ places and could be extracted
+
+Build a candidate table:
+
+| Candidate | Location | Portability         | Reason                  |
+| --------- | -------- | ------------------- | ----------------------- |
+| ...       | ...      | High / Medium / Low | Why it belongs in forge |
+
+### 3. Grill per candidate
+
+For each candidate, grill the operator:
+
+- Is this pattern project-specific or genuinely portable?
+- Does forge already have an equivalent? If so, should the existing one be enhanced instead?
+- What is the minimal extraction that preserves the pattern without project-specific coupling?
+- Does porting this require a new RFC, or can it go through `forge.port.scaffold` directly?
+
+Only proceed with candidates the operator explicitly accepts. Do not port anything without explicit acceptance.
+
+### 4. Port accepted candidates
+
+For each accepted candidate:
+
+1. Run `forge.port.scaffold` to create the skeleton in `packages/forge/`.
+2. Implement the ported logic — inline trivial code, invert dependencies for non-trivial cases.
+3. Run `forge.port.validate` to verify compliance with forge contracts.
+4. Update `FORGE_SKILLS` registry if a new skill was created.
+5. Run `forge.skill.validate` to verify skill frontmatter.
+
+### 5. Registry + docs update
+
+After all accepted candidates are ported:
+
+- Update `packages/forge/AGENTS.md` if new commands or skills were added.
+- Update root `AGENTS.md` if the skill surface changed.
+- Commit with reference to this harvest run.
+
+## Constraints
+
+- **Operator-invoked only.** Never auto-run harvest on a schedule.
+- **One port per candidate.** Do not batch multiple patterns into one port — each candidate gets its own `forge.port.scaffold` call and its own commit.
+- **No hand-copying.** All porting goes through `port-to-forge` / `forge.port.scaffold`. Do not manually copy files into `packages/forge/`.
+- **Grilling is mandatory.** Every candidate must pass the grilling step before porting. No silent ports.
+- **Forward-only.** If a pattern replaces an existing forge skill or command, the old one is removed in the same change — no parallel implementations.

package/skills/fo/fo-idea/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: fo-idea
+description: Analyze a user's idea, decompose if too large, and route to fo-idea-create-rfc or fo-idea-create-adr. Use when the user describes a change and is unsure if it needs an RFC or ADR.
+invocation: user
+category: fo
+concerns: document-only
+dependsOn: ['my-preferences']
+languagePolicy: ref(PREFERENCES.md)
+bindings:
+  requires: []
+  optional: [paths.invariantsFile]
+triggers: ["I have an idea for a change", "analyze this idea and route it", "decompose this feature idea"]
+---
+
+# Idea → RFC or ADR
+
+Before starting, read `PREFERENCES.md` at the repository root. If the file is missing or `aiLanguage` is unset, ask the operator once and create the file using the `my-preferences` skill semantics.
+
+> **This is a document-only skill.** It produces RFC and/or ADR files in `docs/rfcs/` or `docs/adrs/` — nothing else. It must never modify, create, or delete source code files in `apps/`, `packages/`, `services/`, or any other directory. It must not run build commands, tests, or validation suites. If the operator's description sounds like a concrete implementation task (e.g. "replace fonts", "add a button", "fix the sitemap"), that is expected — this skill's job is to **create the document that precedes implementation**, not to implement the change itself. Implementation is handled by `fo-idea-implement` after the document is accepted.
+
+Analyze the operator's text to determine whether the task requires a single RFC, a single ADR, or a **series** of documents. When a series is needed, decompose the task into atomic decisions, classify each, and create all documents in dependency order.
+
+## Process
+
+### 1. Analyze the request
+
+Read the operator's description and identify:
+
+- **What is being decided** — the core decision or change.
+- **What is affected** — packages, apps, commands, DNA invariants, AGENTS.md rules, existing RFCs.
+- **The blast radius** — is this local to one package/app, or does it cross workspace boundaries?
+- **The atomic decisions** — can the task be cleanly split into independent decisions that each stand alone as RFCs or ADRs?
+
+**Implementation-language guard.** The operator may describe the task in concrete implementation terms ("replace the fonts", "add italic support", "switch to self-hosted fonts", "add a new check command"). This is normal — the operator is describing the _what_, not asking for the _how right now_. This skill converts that description into a governance document. Do not interpret concrete language as a request to start coding. If the description is ambiguous between "create a document" and "implement now", ask one clarifying question using `ask_user_question`:
+
+> "This sounds like a concrete change. Should I create an RFC/ADR draft for it, or do you want me to implement it directly?"
+>
+> Recommended option: "Create RFC/ADR draft" — because this skill is `fo-idea`, not `fo-idea-implement`.
+
+Default to document creation. Only route to implementation if the operator explicitly says "implement" or "don't create a document, just do it".
+
+### 1a. Accepted-decision fast path
+
+When the operator signals that a decision is **already made** and provides justification, the skill must take a fast path. Recognition signals include:
+
+- Explicit markers: "принятое решение", "accepted decision", "we decided", "decision:", "решение:", "we use", "используем", "standard:", "правило:"
+- The text includes a full rationale or justification (not just a question or vague idea)
+- The text reads as a pronouncement, not a proposal
+
+When the accepted-decision fast path is triggered:
+
+1. **Classify using the decision table in step 3a** — but do not ask clarifying questions unless the table is genuinely ambiguous after reading the full justification.
+2. **If ADR**: invoke `/fo-idea-create-adr` inline, but **skip grilling** — the operator has already decided and justified. Tell `fo-idea-create-adr` to skip its step 4 (grilling) by passing the operator's justification as the ADR's `Justification` section directly. Proceed to file creation, fill all sections from the operator's text, validate, and report.
+3. **If RFC**: still invoke `/fo-idea-create-rfc` with full grilling — RFCs govern cross-workspace contracts and need stress-testing even when the operator has decided.
+4. **Do not search for RFC numbers, run `rfc.list`, or scan the `docs/rfcs/` directory** when the classification is ADR. This is a waste of time and a misclassification signal.
+
+The fast path does **not** skip validation (`adr.validate` / `rfc.validate`) — only the grilling step is skipped for ADRs.
+
+### 2. Assess scope: single document or series?
+
+A task needs a **series** when **any** of the following is true:
+
+- The task introduces multiple new Site OS commands across different domains (e.g. a new check command + a new codegen command + a new build pipeline command).
+- The task spans multiple independent package boundaries with separate concerns (e.g. changes to multiple shared packages that are each independently useful).
+- The task naturally decomposes into phases with clear dependency edges (e.g. a contract definition RFC must be accepted before a command implementation RFC that depends on it).
+- A single RFC's Design section would be unmanageably long — covering unrelated files, unrelated type signatures, and unrelated failure modes.
+- The task amends multiple existing RFCs in unrelated areas.
+- Some parts are local (ADR) and some are cross-workspace (RFC), and the local parts do not depend on the RFC parts.
+
+A task is a **single document** when:
+
+- All decisions are tightly coupled and cannot stand alone.
+- The task is local to one package/app with one coherent decision.
+- Splitting would produce documents that reference each other so heavily that they cannot be read independently.
+
+If the task is a single document, proceed to step 3 (classify and create).
+
+If the task needs a series, proceed to step 4 (decompose).
+
+### 3. Single document: classify and create
+
+#### 3a. Classify: RFC or ADR
+
+Use the following decision table:
+
+| Criterion | RFC | ADR | Examples |
+| --- | --- | --- | --- |
+| Adds, removes, or changes a Site OS command | yes | no | New `fonts.selfhost.validate` command; changing `content.surface.validate` behavior |
+| Modifies a DNA invariant or AGENTS.md rule | yes | no | Changing the cosmic naming contract; adding a new storage policy to AGENTS.md |
+| Establishes a cross-workspace package boundary or contract | yes | no | New shared package exported schema; new package interface; inter-package type contract |
+| Changes a currently accepted or implemented RFC | yes | no | Amending RFC-XXXX content surface; superseding RFC-XXXX |
+| Introduces a new policy or governance process | yes | no | RFC lifecycle process; feature visibility policy; verification evidence pipeline |
+| A convention, standard, or tooling choice applied across apps | no | yes | "Use Fontsource for all fonts"; "Self-host Playfair Display"; CSS methodology; lint rule choices |
+| Local to one package, one app, or one narrow convention | no | yes | Changing a biome's typography tokens; adding a font family to the self-host registry |
+| Does not touch commands, DNA, AGENTS.md, or cross-workspace contracts | no | yes | Choosing a library; picking a CSS token naming scheme; selecting an image format strategy |
+
+**If any RFC criterion is met → RFC.** Only if all ADR criteria are met and no RFC criterion applies → ADR.
+
+#### Common misclassification traps
+
+These patterns **look like RFCs but are ADRs**:
+
+- **"Applied to all apps" ≠ "cross-workspace contract"** — a convention like "use Fontsource for fonts" or "self-host all web fonts" applies everywhere but does not create a package boundary, inter-package type contract, or new command. It is an ADR with `scope: workspace`.
+- **"Changes a shared package" ≠ "establishes a package boundary"** — extending `packages/os/site-kernel-checks/src/fonts.ts` with a new font family modifies shared code, but the decision is about which fonts to use, not about the package's interface or contract. ADR.
+- **"Might be mentioned in AGENTS.md" ≠ "modifies a DNA invariant"** — a decision might be documented in AGENTS.md for visibility, but unless it changes a DNA-NN invariant or a governance rule, it is an ADR.
+- **"Has cross-app impact" ≠ "cross-workspace contract"** — adding a font to the shared registry affects all apps' builds, but the decision itself is a tooling/standard choice, not a contract between packages.
+
+These patterns **look like ADRs but are RFCs**:
+
+- **"Just adding one field to a schema"** — if the schema is a cross-workspace contract (e.g. a shared package exported types), changing it is an RFC even if the diff is small.
+- **"It's only a convention"** — if the convention is enforced by a new Site OS command or validator, it needs an RFC to define the command.
+- **"It's local to one package"** — if that package's change breaks an accepted RFC or changes a DNA invariant, it needs an RFC.
+
+If the classification is ambiguous (e.g. the operator's description is too vague), ask a clarifying question using `ask_user_question` with the recommended classification first.
+
+#### 3b. Invoke the creation skill inline
+
+Once classified, invoke the matching skill **inline** — execute it fully without stopping or returning control to the user:
+
+- **RFC** → invoke `/fo-idea-create-rfc`. It will collect metadata, grill the concept, create the file, fill it, validate, and report.
+- **ADR** → invoke `/fo-idea-create-adr`. It will collect metadata, grill the concept, create the file, fill it, validate, and report. **On the accepted-decision fast path (step 1a)**, tell `fo-idea-create-adr` to skip grilling and use the operator's justification text directly.
+
+Do not duplicate the creation skill's work — just route to it and let it run.
+
+#### 3c. Report
+
+After the creation skill completes, present its final report to the user in `aiLanguage`. Add a one-line prefix indicating which path was taken — translate the label to `aiLanguage`:
+
+```
+<Classified as in aiLanguage>: RFC (cross-workspace command addition) / ADR (local package convention)
+```
+
+Followed by the creation skill's own report.
+
+### 4. Series: decompose, classify, and create each document
+
+#### 4a. Decompose into atomic decisions
+
+Break the task into the smallest set of independent decisions such that:
+
+- Each decision can be read, reviewed, accepted, and implemented on its own.
+- Each decision has a clear, single-sentence Decision statement.
+- Dependencies between decisions are explicit (document A must be accepted before document B can be implemented).
+- No decision is so small that it would be better as a section of another document.
+
+For each atomic decision, record:
+
+- **Title** — short imperative sentence.
+- **Type** — RFC or ADR (use the decision table from step 3a).
+- **Scope** — `workspace`, `package`, or `app`.
+- **Depends on** — other documents in this series that must be accepted first.
+- **Summary** — one or two lines describing what this document decides.
+
+#### 4a-spec. Spec escalation check
+
+After decomposition, check whether this is a **specification**, not a document series:
+
+- If decomposition yields **more than 7 atomic decisions** with at least one dependency edge, OR
+- The operator's description mentions waves/stages/data migration across many documents
+
+Then propose escalation using `ask_user_question`:
+
+> "This is a specification, not a document series. Create a spec package via fo-spec-ingest authoring mode?"
+
+- **Recommended option**: "Create spec package" — because a pre-designed roadmap with 65 nodes is a spec, not a series of independent RFCs.
+- **Alternative**: "Continue as series" — the operator may decline and stay with the series path.
+
+If the operator accepts escalation, invoke `/fo-spec-ingest` in authoring mode, passing the decomposition results. Do not continue with the series creation steps below.
+
+#### 4b. Present the decomposition plan
+
+Present the full plan to the operator before creating any files, in `aiLanguage`. **Translate all labels and headings to `aiLanguage`** — the template below is structural only.
+
+```
+## <Decomposition Plan in aiLanguage>
+
+This task requires <N> documents:
+
+1. **<Title 1>** — <RFC|ADR> (scope: <scope>)
+   Depends on: none
+   <one-line summary>
+
+2. **<Title 2>** — <RFC|ADR> (scope: <scope>)
+   Depends on: <Title 1>
+   <one-line summary>
+
+...
+
+### Creation order: 1 → 2 → ... → N
+```
+
+Ask the operator to confirm or adjust the decomposition using `ask_user_question`. Do not proceed to creation until the plan is confirmed.
+
+#### 4c. Create each document in dependency order
+
+Process documents **sequentially in dependency order** — foundational documents first. For each document:
+
+1. Invoke the appropriate creation skill **inline** (`/fo-idea-create-rfc` or `/fo-idea-create-adr`).
+2. When the creation skill collects metadata, include the cross-references:
+   - **`related`** — list all other documents in the series by their assigned id (once created) or by title (if not yet created).
+   - **`amends`** — if a document in the series amends an existing accepted RFC, set the `amends` field.
+3. The creation skill will grill, create, fill, validate, and report — let it run fully.
+4. After each document is created, record its assigned id for use in subsequent documents' `related` fields.
+5. Do not pause between documents in the series — continue to the next immediately.
+
+If a creation skill's grilling reveals that a document in the series is unnecessary (the decision is already covered by an existing RFC/ADR), skip it and note this in the final report. If grilling reveals that a missing document is needed, add it to the plan and create it in the correct dependency position.
+
+#### 4d. Series report
+
+After all documents are created, present a single batch report in `aiLanguage`. **Translate all labels, headings, and column names to `aiLanguage`** — the template below is structural only.
+
+```
+## <Series Creation Summary in aiLanguage>
+
+### Task: <original operator request — one line>
+### Documents created: <N>
+
+| # | ID | Type | Title | Depends on | Status |
+| --- | --- | --- | --- | --- | --- |
+| 1 | RFC-XXXX | RFC | <title> | — | draft |
+| 2 | ADR-XXXX | ADR | <title> | RFC-XXXX | proposed |
+| 3 | RFC-XXXX | RFC | <title> | RFC-XXXX | draft |
+...
+
+### Next steps
+- Human architecture review for all RFC drafts (status may not change before acceptance).
+- ADRs are ready for the named decider to accept.
+- Implement in dependency order: 1 → 2 → 3 → ...
+```
+
+## Constraints
+
+- **Document-only. This skill must never modify, create, or delete source code files.** It must not touch files in `apps/`, `packages/`, `services/`, `tools/`, `scripts/`, or any other source directory. It must not run `pnpm`-based builds, `pnpm test`, `astro check`, or any build/validation command other than `rfc.validate` / `adr.validate` (which run inside the delegated creation skills). The only files this skill may produce are RFC files in `docs/rfcs/` and ADR files in `docs/adrs/` — and even those are created by the delegated `fo-idea-create-rfc` / `fo-idea-create-adr` skills, not by this skill directly. If you feel the urge to "quickly fix something in the code while I'm here" — stop. That is not this skill's job.
+- **Classify before invoking.** Do not invoke both skills for one document — pick one based on the decision table.
+- **When genuinely ambiguous, ask — do not default to RFC.** Conventions, tooling choices, library selections, and standards applied across apps are ADRs even when they touch shared packages. Defaulting to RFC for every cross-app decision clogs the RFC pipeline and wastes architecture review time on local technical choices. If the table and examples do not resolve the classification, ask the operator with `ask_user_question` presenting both options. Reserve RFC for decisions that genuinely change commands, DNA, AGENTS.md rules, cross-workspace contracts, or governance process.
+- **Do not skip the creation skill's grilling step — except on the accepted-decision fast path (step 1a).** When the operator has signaled an already-made decision with justification and the classification is ADR, grilling is skipped because the operator has already decided. In all other cases, grilling happens inside the invoked skill — this skill only routes.
+- **Do not create files directly.** This skill never writes RFC or ADR files — it delegates to `fo-idea-create-rfc` or `fo-idea-create-adr`.
+- **Decomposition must produce independent documents.** Each document in a series must be readable, reviewable, and implementable on its own. If two decisions cannot be separated, keep them in one document.
+- **Cross-reference all documents in a series.** Every document in a series must list all other documents in the series in its `related` field. Update `related` fields as ids are assigned.
+- **Respect dependency order.** A document that depends on another must not be created before its prerequisite — the prerequisite's id is needed for the `related` field.
+- **Commit only your own files.** Stage only the files this skill produces or modifies — RFC/ADR files and nothing else. Do not stage unrelated changes. Another agent may be working in a different session; `git add -A` or `git add .` is forbidden.
+- **Present the decomposition plan before creating files.** The operator must confirm the decomposition before any document is created. Adjust if requested.

package/skills/fo/fo-idea-audit/SKILL.md

@@ -0,0 +1,248 @@
+---
+name: fo-idea-audit
+description: Audit RFCs for ecosystem fit, DNA alignment, forward-only compliance, agent policy, and pragmatism. Accepts a single id, list, or range. Use after creating or revising an RFC.
+invocation: user
+category: fo
+concerns: read-only
+dependsOn: ['my-preferences']
+languagePolicy: ref(PREFERENCES.md)
+bindings:
+  requires: [commands.validateRfc]
+  optional: [paths.invariantsFile, paths.compassDocs]
+triggers: ["audit this RFC", "check RFC for ecosystem fit", "review RFC against DNA and forward-only rules"]
+---
+
+# RFC Audit
+
+Before starting, read `PREFERENCES.md` at the repository root. If the file is missing or `aiLanguage` is unset, ask the operator once and create the file using the `my-preferences` skill semantics.
+
+A read-only semantic review of an RFC against the ecosystem's actual structure, DNA invariants, and governance rules. The audit finds what `rfc.validate` cannot: drift between the RFC's claims and the ecosystem's reality, over-engineering, missing operational details, and agent-facing policy gaps.
+
+The audit does **not** modify the RFC or any other file. It produces a structured report, persists it to `docs/audits/`, and stops.
+
+## Process
+
+### 1. Identify the RFC(s)
+
+The user may provide:
+
+- **A single RFC**: `RFC-XXXX`, a filename, or a path.
+- **A comma-separated list**: `RFC-XXXX, RFC-XXXX, RFC-XXXX` — process each in order.
+- **A range**: `RFC-XXXX..RFC-XXXX` or `от RFC-XXXX до RFC-XXXX` — discover all RFC files in `docs/rfcs/` whose numeric id falls within the inclusive range, sort ascending, and process each in order.
+- **Nothing**: if an RFC file is open in the IDE, use it. Otherwise, ask.
+
+### 1.5. Prerequisite checks (per RFC)
+
+Before running the audit on each RFC, perform these checks **in order**. If any check fails, record the RFC as **skipped** in the batch summary with the reason, and immediately proceed to the next RFC in the batch. Do not stop the entire batch — skip and report.
+
+1. **Prefix check** — if the id starts with `ADR-`, this is not an RFC. Skip with message: `ADR-XXXX is an ADR, not an RFC. ADRs do not have an audit step. The ADR pipeline is: create → implement. Run /fo-idea-implement ADR-XXXX to implement.`
+
+2. **RFC file exists** — look for `docs/rfcs/rfc-XXXX-*.md`. If no file is found, skip with message: `RFC-XXXX not found in docs/rfcs/. Run /fo-idea-create-rfc first.`
+
+3. **Terminal status check** — read the RFC's `status` frontmatter. If the status is `implemented`, `rejected`, or `superseded`, skip with message: `RFC-XXXX is <status> (terminal). Terminal RFCs cannot be audited. To change this decision, create a new RFC with supersedes: [RFC-XXXX] via /fo-idea-create-rfc.`
+
+If all checks pass, proceed to step 2 for this RFC.
+
+### 1.6. Batch processing
+
+When multiple RFCs are identified, **loop through each one** and run the full audit (steps 2–8) for each RFC sequentially **without pauses between RFCs**. Do not stop, present a summary, or ask the user between RFCs — once the audit report for one RFC is persisted and committed (or it is skipped), immediately proceed to the next RFC. **Do not emit transition messages such as "Moving to RFC-XXXX next" or per-RFC status reports during the loop.** Internal status is fine, but nothing is shown to the user until the very end. Only after all RFCs are processed, print a single final batch summary.
+
+Read the full RFC file at `docs/rfcs/rfc-XXXX-*.md` for the first RFC to process.
+
+### 2. Run mechanical validation
+
+Run the mechanical floor first — it catches format, referential, and structural violations that don't need semantic judgment:
+
+```sh
+ref(forge.yaml bindings.commands.validateRfc) --json
+```
+
+Record any violations targeting this RFC. The semantic audit starts from a clean mechanical baseline; if `rfc.validate` already fails on this RFC, report it and still continue with the semantic axes — the human needs the full picture.
+
+### 3. Load ecosystem context
+
+Read the context the RFC claims to fit into:
+
+- `ref(forge.yaml bindings.paths.invariantsFile)` — all DNA invariants referenced in `satisfies[]` or `related[]`.
+- `AGENTS.md` (root) — RFC governance protocol, storage policy, cosmic naming contract, Compass duties, CKL, agent surface.
+- The closest nested `AGENTS.md` for the RFC's scope (`docs/authoring/site-composition.md`, `packages/AGENTS.md`, `services/AGENTS.md`).
+- Each RFC listed in `amends[]`, `supersedes[]`, `related[]` — read enough to understand what this RFC builds on or changes.
+- `docs/requirements.xml`, `docs/technology.xml`, `docs/development-plan.xml` — if the RFC is workspace-scoped or architectural.
+- The package manifests (`package.json`) of any `packagesImpacted` entries — verify the package exists and check its current exports.
+
+Do not read every RFC in the repo — only those the RFC explicitly references, plus the DNA and AGENTS files.
+
+### 4. Run the seven audit axes
+
+For each axis below, check every item. An item either **passes**, **fails** (specific finding with evidence), or is **not applicable** (state why). Skip N/A items silently — do not pad the report.
+
+#### Axis A — Structural completeness
+
+Beyond V-13 (required sections exist) and V-14 (≥3 acceptance items), check that each section contains real content, not template placeholders or empty HTML comments:
+
+- **Decision** is a single decision in present tense ("The kernel gains…"), not a wishlist or "we should".
+- **CLI surface** shows exact command invocations with flags and scope (resolved from `ref(forge.yaml bindings.commands.*)`).
+- **TypeScript contracts** are minimal type signatures, not full implementations.
+- **File system responsibilities** table names concrete paths the RFC touches.
+- **Output format** documents the `--json` shape.
+- **Failure modes** specifies exit codes and warn-vs-fail behavior.
+- **Rollout** describes default behavior, adoption path for existing apps, and new-app compliance.
+- **Alternatives considered** is honest — at least one real alternative with a rejection reason.
+- **Risks** includes agent misinterpretation risk and false-positive rate for validators.
+- **Acceptance criteria** items are checkable (can an agent or human verify each one?) and sufficient (do they cover the decision's full scope?).
+- **Implementation notes for agents** are explicit behavioral rules, not vague guidance.
+
+#### Axis B — DNA alignment
+
+- Each entry in `satisfies[]` is a real DNA invariant in `ref(forge.yaml bindings.paths.invariantsFile)`, and the RFC body explains **how** it enforces, protects, or extends that invariant — not just that it's "related".
+- If the RFC establishes a new DNA invariant (body says "DNA-N established by this RFC"), the audit confirms `ref(forge.yaml bindings.paths.invariantsFile)` will need a new `## DNA-N` entry and the RFC's `satisfies[]` includes it.
+- The RFC does not silently conflict with any existing DNA invariant. If it changes a DNA invariant, it must `supersede` the establishing RFC — not amend it.
+- `related[]` DNA references are relevant and not decorative.
+
+#### Axis C — Ecosystem fit
+
+- **Package boundaries**: imports flow `apps/* → packages/*` and `services/* → packages/*`, never `apps/* → apps/*` or `apps/* → services/*`. If the RFC proposes a new package, it belongs in `packages/*`. Check the project's invariants file for the canonical boundary rule.
+- **Pipeline placement**: the RFC names the correct pipeline for each new check — `build.prepare`, `build.check`, `sites-check`, `sites-check-postbuild` — and the choice is justified (blocking vs. advisory).
+- **Compass sync**: if the RFC changes repository-wide requirements, shared package contracts, or app-package relationships, it identifies which `docs/*.xml` files need synchronization (root AGENTS.md Compass document duties).
+- **AGENTS.md updates**: the RFC identifies which `AGENTS.md` files need rule updates (root, `apps/`, `packages/`, `services/`, or site-specific).
+- **Cosmic naming**: if the RFC touches manifests or component/section/page contracts, it addresses the three-way alignment (manifest `cosmicName` ↔ `PLANET_IMPORT_PATHS`/`MOON_IMPORT_PATHS` ↔ `system.md` pins).
+- **Command lifecycle**: `commands.proposed/added/changed/removed` buckets are internally consistent — proposed commands that the RFC introduces will land in `added` upon implementation; changed commands are existing registered commands; removed commands are explicitly deprecated.
+
+#### Axis D — Forward-only compliance
+
+This ecosystem is forward-only — no backward compatibility layers, no expand-then-contract migrations. Check:
+
+- The RFC does not propose a compatibility shim, bridge, or dual-path that keeps legacy behavior alive alongside the new one.
+- Deprecation means removal in the same RFC wave, not an indefinite grace period.
+- If the RFC amends another RFC, it changes the amended RFC's contract directly — it does not add a parallel interpretation.
+- Legacy code paths are deleted, not maintained behind a flag.
+
+#### Axis E — Agent-facing policy
+
+- **Status gate**: the RFC does not contain self-authorizing language ("may proceed while draft", "implementation can start before acceptance"). Draft RFCs cannot grant implementation permission.
+- **Implementation notes** reference the correct governance rules: RFC-XXXX (accepted→implemented transition), RFC-XXXX (if touching agent surface), RFC-XXXX (supersede escalation on invariant conflict), RFC-XXXX (verification evidence for probe-bearing RFCs).
+- **Anti-fabrication**: if the RFC's acceptance criteria include content authoring (prose, business records, claims), the criteria distinguish between code changes an agent can make and content that requires human authoring. The RFC must not claim content will be "auto-generated" when it requires human authoring.
+- **Storage policy**: if the RFC touches persistence, it does not introduce cookies (`document.cookie`, `Set-Cookie`). Client-side persistence is `localStorage` only; server-side is `unstorage`.
+
+#### Axis F — Pragmatism
+
+- **Minimal command surface**: each proposed command earns its existence — no command that could be a flag on an existing command, no command that duplicates an existing command's scope.
+- **Lean contracts**: TypeScript types are the minimum needed to understand the shape — no speculative generality, no unused optional fields, no abstraction for needs the RFC doesn't have.
+- **Existing patterns**: the RFC checks whether an existing command, schema, or pattern can be extended before proposing a new one. If a new one is proposed, the alternatives section explains why extension was insufficient.
+- **Scope discipline**: `appsImpacted` and `packagesImpacted` list only what's actually impacted. `nonGoals` are explicit and meaningful, not boilerplate.
+
+#### Axis G — Blind spots
+
+- **Performance**: build-time commands specify their cost (file scan count, regex complexity, I/O patterns). A command that scans all `apps/**` on every `build.check` is a bottleneck.
+- **False positives**: validators estimate their false-positive rate and describe how to suppress noise during migration.
+- **Edge cases**: the RFC considers empty states (new app with no content, package with no manifests), concurrent execution (two builds, two agents), and interrupted operations (crash mid-write).
+- **Migration path**: existing apps' path to compliance is documented — do they pass without changes, or is there a documented migration window?
+- **Security/privacy**: if the RFC touches user data, PII, or external services, it addresses GDPR/privacy implications and secret management (no hardcoded keys, env vars documented in `.env.example`).
+
+### 5. Produce the report
+
+Present the findings in this structure in `aiLanguage`. **Translate all labels, headings, and axis names to `aiLanguage`** — the template below is structural only. Only identifiers (RFC-XXXX, file paths, DNA invariant ids) stay untranslated. Keep it concise — each finding is one to three sentences with evidence (quote the RFC line or cite the file path).
+
+```
+## <RFC-XXXX Audit in aiLanguage>
+
+### Verdict: <Approved | Needs revision | Rejected>
+
+<2-3 sentence justification grounded in the most serious findings.>
+
+### Mechanical validation (rfc.validate)
+
+<Pass / Fail — if fail, list violations targeting this RFC.>
+
+### Axis A — Structural completeness
+<Findings or "No issues.">
+
+### Axis B — DNA alignment
+<Findings or "No issues.">
+
+### Axis C — Ecosystem fit
+<Findings or "No issues.">
+
+### Axis D — Forward-only compliance
+<Findings or "No issues.">
+
+### Axis E — Agent-facing policy
+<Findings or "No issues.">
+
+### Axis F — Pragmatism
+<Findings or "No issues.">
+
+### Axis G — Blind spots
+<Findings or "No issues.">
+
+### Questions for the author
+
+1. <Hard question that the RFC must answer before implementation.>
+2. <Hard question.>
+3. <Hard question.>
+```
+
+**Verdict criteria:**
+
+- **Approved** — zero findings across all axes. Any finding, no matter how minor or cosmetic, disqualifies Approved and forces Needs revision. The rationale: downstream agents treat Approved as a stop signal and stop reading the findings — so even a trivial finding left under Approved gets silently ignored. If there is anything to fix, the verdict must say so.
+- **Needs revision** — one or more findings on any axis, regardless of severity. A one-line cosmetic note is enough. The agent must not downgrade to Approved based on severity — a finding is a finding.
+- **Rejected** — fundamental flaw: the RFC contradicts a DNA invariant without superseding it, proposes a backward compatibility layer, or contains self-authorizing language that bypasses the status gate.
+
+### 6. Persist the audit
+
+Write the report to `docs/audits/` using the `audit-rfc-NNNN-…` prefix pattern (mirroring the `plan-rfc-NNNN-…` convention in `docs/plans/`):
+
+```txt
+docs/rfcs/rfc-0362-werkstatt-consistency-primitives-….md
+  → docs/audits/audit-rfc-0362-werkstatt-consistency-primitives-….md
+```
+
+Use `docs/audits/audit-0000-template.md` as the structural starting point. The file must begin with a YAML frontmatter block:
+
+```yaml
+---
+rfcId: RFC-XXXX
+auditId: AUDIT-RFC-XXXX-01
+date: YYYY-MM-DD
+auditor:
+  skill: fo-idea-audit
+  model: <AI model identifier>
+verdict: <approved | needs-revision | rejected>
+---
+
+# Audit: RFC-XXXX
+
+(…report body…)
+```
+
+The `auditor.model` field must record the AI model identifier the skill is running on (e.g. `claude-sonnet-4-20250514`, `gpt-4o`, etc.). If the model cannot be determined, use `unknown`.
+
+If the file already exists, overwrite it — the audit is always the latest run.
+
+### 7. Commit
+
+Commit the audit report. This is **mandatory** — the audit file must be committed, not left in the working tree.
+
+Commit message format:
+
+```txt
+audit: RFC-XXXX <short description>
+
+Semantic audit of RFC-XXXX (<title>). Verdict: <approved | needs-revision | rejected>.
+```
+
+Stage only the audit file — do not stage unrelated changes. Another agent may be working in a different session; `git add -A` or `git add .` is forbidden.
+
+### 8. Stop
+
+Do not modify the RFC or any other file. Do not run `/fo-idea-plan` or `/fo-idea-implement` — those are separate skills with different purposes. Present the report and stop. If the user asks to fix the findings, suggest running `/fo-idea-enhance` — it reads the persisted audit and applies the fixes. The full pipeline is: create → audit → enhance → plan → implement.
+
+## Constraints
+
+- The audit is **read-only** with respect to the RFC and codebase — the only file it writes is the audit report in `docs/audits/`.
+- **Commit the audit report.** The audit file must be committed after persistence — never left in the working tree.
+- The audit does **not** duplicate `rfc.validate` — it starts from the mechanical floor and goes beyond it.
+- The audit does **not** assess writing style, prose quality, or formatting — only semantic and architectural correctness.
+- The audit does **not** approve or reject RFCs for architecture acceptance — that is a human-only decision. The verdict is advisory.
+- The audit must ground every finding in evidence: quote the RFC line, cite the DNA invariant, or reference the file path. No ungrounded assertions.
+- **No pauses for recoverable tool errors.** If a tool call fails with a recoverable error — e.g. `write_to_file` content too long, JSON truncation, line count/character limit exceeded, or similar — do not stop and ask the user. Recover autonomously: split the content into smaller writes, use `edit`/`multi_edit`, decompose oversized files, and retry immediately. The operator's default answer to "Shall I proceed?" is always "yes".