@warpgogol/forge 0.22.0 → 0.24.0

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

@@ -0,0 +1,145 @@
+---
+name: fo-explore
+description: Explore an idea in the codebase without creating an RFC or ADR. Produces a markdown exploration note in docs/explorations/. Use when weighing options before committing to a specification.
+invocation: user
+category: fo
+concerns: document-only
+dependsOn: ['my-preferences']
+languagePolicy: ref(PREFERENCES.md)
+bindings:
+  requires: [paths.invariantsFile]
+  optional: []
+triggers: ["explore this idea", "let me think about this", "what are the options for", "what if we"]
+---
+
+# Explore an idea before specification
+
+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 exploration notes in `docs/explorations/` — nothing else. It must never modify, create, or delete source code files. It must not run build commands, tests, or validation suites. Exploration notes are not governance documents — they have no status transitions, no validation, and no acceptance step. They are informational artifacts that may precede an RFC or ADR.
+
+## Process
+
+### 1. Read the idea
+
+The operator describes what they want to explore. Identify:
+
+- **What is being explored** — the core question or idea.
+- **Why exploration is needed** — is the operator unsure about approach, feasibility, or scope?
+- **What constraints are known** — packages, DNA invariants, existing RFCs, timeline.
+
+### 2. Explore the codebase
+
+Search for relevant code, existing patterns, constraints, and dependencies. This is interactive — ask clarifying questions if the idea is vague. Use `code_search`, `grep_search`, and `read_file` to understand the current state of the codebase.
+
+If the codebase is empty or inaccessible, document the constraint and focus on option analysis without codebase findings.
+
+### 3. Weigh options
+
+Present 2–5 options with trade-offs. For each option:
+
+- **Approach** — a brief description of how the idea would be implemented.
+- **Trade-offs** — pros and cons.
+- **DNA alignment** — which invariants from `ref(forge.yaml bindings.paths.invariantsFile)` are relevant.
+- **Blockers** — what needs to be resolved first (missing schema, missing command, conflicting RFC).
+- **Estimated effort** — small / medium / large.
+
+### 4. Assess feasibility
+
+For each option, identify:
+
+- **Blockers** — missing infrastructure, conflicting decisions, missing RFCs.
+- **Required RFCs** — does this option need a new RFC or ADR before implementation?
+- **Estimated effort** — small / medium / large.
+
+### 5. Persist the exploration note
+
+Write `docs/explorations/<slug>.md` using the exploration note format below. The slug must be kebab-case, lowercase, latin-only (matching the project naming convention).
+
+If the file already exists, append a new exploration section with a timestamp header instead of overwriting.
+
+After persisting, transition the note's `status` from `open` to `explored` by editing the frontmatter directly. This skill is `concern: document-only` and may edit `.md` files — no separate command is needed for this transition.
+
+### 6. Suggest next steps
+
+Recommend whether to:
+
+- **Create an RFC** — the exploration identified a cross-workspace change that needs governance.
+- **Create an ADR** — the exploration identified a local decision that needs recording.
+- **Shelve the idea** — the exploration revealed blockers or insufficient value.
+- **Explore further** — the exploration raised more questions than it answered.
+
+## Exploration note format
+
+```markdown
+---
+id: <slug>
+title: "<exploration title>"
+createdAt: YYYY-MM-DD
+status: open
+related: []
+---
+
+# Exploration: <title>
+
+## Idea
+
+<operator's description>
+
+## Codebase findings
+
+<what the agent found in the codebase — relevant files, existing patterns, constraints>
+
+## Options
+
+### Option 1: <name>
+- **Approach:** <description>
+- **Trade-offs:** <pros/cons>
+- **DNA alignment:** <which invariants are relevant>
+- **Blockers:** <what needs to be resolved first>
+- **Estimated effort:** <small/medium/large>
+
+### Option 2: <name>
+...
+
+## Recommendation
+
+<agent's recommendation with rationale>
+
+## Open questions
+
+- <unresolved questions for the operator>
+```
+
+## Frontmatter fields
+
+| Field | Type | Description |
+| --- | --- | --- |
+| `id` | string | Kebab-case slug, matches filename |
+| `title` | string | Human-readable title |
+| `createdAt` | date | Creation date |
+| `status` | enum | `open` (exploration in progress), `explored` (exploration complete, awaiting decision), `archived` (superseded by RFC or shelved) |
+| `related` | string[] | RFC/ADR ids that materialized from this exploration |
+
+## File system responsibilities
+
+| Path                          | Role                                     |
+| ----------------------------- | ---------------------------------------- |
+| `docs/explorations/<slug>.md` | Exploration note (created by this skill) |
+| `docs/explorations/`          | Directory for all exploration notes      |
+
+## Failure modes
+
+- **Exploration note already exists:** Append a new exploration section with a timestamp header instead of overwriting.
+- **Invalid slug:** Slugs must be kebab-case, lowercase, latin-only. Invalid slugs are rejected by `exploration.archive` — exit code 1.
+- **No codebase access:** Document the constraint and focus on option analysis without codebase findings.
+- **Slug not found:** `exploration.show` and `exploration.archive` return exit code 1 if the slug does not exist.
+- **Already archived:** `exploration.archive` is idempotent — if the note is already `archived`, it returns exit code 0 with `previousStatus: "archived"` (no-op).
+- **Empty directory:** `exploration.list` returns `{ explorations: [] }` with exit code 0 when `docs/explorations/` is empty or does not exist.
+
+## Constraints
+
+- **No source code changes.** This skill is `concern: document-only`. It may only create and edit `.md` files in `docs/explorations/`.
+- **No governance authority.** Exploration notes are not RFCs or ADRs. They do not define contracts, policies, or decisions. They are informational artifacts.
+- **No pipeline integration.** Exploration notes are not part of any build or validation pipeline. They are discoverable via `exploration.list` and by browsing `docs/explorations/`.
+- **Bindings compliance.** Use `ref(forge.yaml bindings.*)` references for paths and commands — no hardcoded project literals in skill instruction lines.

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

@@ -1,6 +1,6 @@
 ---
 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.
+description: Analyze a user's idea, decompose if too large, and route to fo-idea-create-rfc, fo-idea-create-adr, or direct implementation. Use when the user describes a change and is unsure if it needs an RFC, ADR, or no document.
 invocation: user
 category: fo
 concerns: document-only
@@ -9,10 +9,10 @@ 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"]
+triggers: ["I have an idea for a change", "analyze this idea and route it", "decompose this feature idea", "does this need an RFC", "should I write an ADR for this"]
 ---
 
-# Idea → RFC or ADR
+# Idea → RFC, ADR, or direct implementation
 
 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.
 
@@ -39,6 +39,16 @@ Read the operator's description and identify:
 
 Default to document creation. Only route to implementation if the operator explicitly says "implement" or "don't create a document, just do it".
 
+### 1b. Explore suggestion
+
+If the operator's description is ambiguous, exploratory, or contains phrases like "what are the options", "let me think about", "explore", or "what if we", suggest using `fo-explore` before creating an RFC. Use `ask_user_question`:
+
+> "This sounds like an exploration rather than a settled decision. Should I explore the codebase first, or create an RFC/ADR draft directly?"
+>
+> Recommended option: "Explore first" — because exploration is low-commitment and the results inform a better RFC.
+
+If the operator chooses "Explore first", invoke `/fo-explore` inline. Do not proceed to classification or document creation in this invocation — `fo-explore` will produce an exploration note and suggest next steps, which may include creating an RFC or ADR in a separate invocation.
+
 ### 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:
@@ -79,22 +89,28 @@ If the task needs a series, proceed to step 4 (decompose).
 
 ### 3. Single document: classify and create
 
-#### 3a. Classify: RFC or ADR
+#### 3a. Classify: RFC, ADR, or direct implementation
 
 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.
+| Criterion | RFC | ADR | Direct | Examples |
+| --- | --- | --- | --- | --- |
+| Adds, removes, or changes a Site OS command | yes | no | no | New `fonts.selfhost.validate` command; changing `content.surface.validate` behavior |
+| Modifies a DNA invariant or AGENTS.md rule | yes | no | no | Changing the cosmic naming contract; adding a new storage policy to AGENTS.md |
+| Establishes a cross-workspace package boundary or contract | yes | no | no | New shared package exported schema; new package interface; inter-package type contract |
+| Changes a currently accepted or implemented RFC | yes | no | no | Amending RFC-XXXX content surface; superseding RFC-XXXX |
+| Introduces a new policy or governance process | yes | no | no | RFC lifecycle process; feature visibility policy; verification evidence pipeline |
+| Introduces new information architecture (new page sections, new content blocks, new UI structures visible to users) | yes | no | no | Adding a new section to the homepage; introducing a new block type on a page; projecting new fields into content before the backing implementation exists |
+| A convention, standard, or tooling choice applied across apps | no | yes | no | "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 | no | 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 | no | Choosing a library; picking a CSS token naming scheme; selecting an image format strategy |
+| Bug fix restoring intended behavior within existing contracts | no | no | yes | Fixing a broken import path; correcting a typo in a label; restoring a pipeline step that was accidentally bypassed |
+| Content data correction (fixing a fact, updating a status field, correcting a hash) | no | no | yes | Fixing a SHA-256 hash to match the real file; updating a consent status from `not_requested` to `requested` |
+| Cosmetic or formatting change with no semantic or structural impact | no | no | yes | Fixing indentation; reordering imports; renaming a local variable for readability |
+
+**If any RFC criterion is met → RFC.** If no RFC criterion applies and any ADR criterion is met → ADR. If no RFC or ADR criterion applies and a Direct criterion is met → direct implementation (no document needed).
+
+**Key insight:** Adding new user-visible structures to a site (new page sections, new content blocks, new homepage blocks, projecting not-yet-implemented fields into content) is an architectural change to the site's information architecture, not a data fix. It requires an RFC even when the change is "only content files". The test is: does this change what the site communicates or how it is structured? If yes → RFC. If it only corrects existing data within existing structures → direct.
 
 #### Common misclassification traps
 
@@ -110,15 +126,23 @@ 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.
+- **"It's only content files, not code"** — adding new page sections, new content blocks, or projecting not-yet-implemented fields into content is an information-architecture change, not a data fix. It requires an RFC even when no `.ts` or `.astro` file is touched. The test is whether the change introduces new user-visible structures or semantics, not whether it touches code files.
+
+These patterns **look like they need a document but are direct implementation**:
+
+- **"Fixing content data"** — correcting a hash, updating a status field, or fixing a factual error in existing content is a data correction within existing structures, not an architectural change. Direct implementation.
+- **"Restoring broken behavior"** — a bug fix that restores the intended behavior within existing contracts is direct implementation, not an RFC. (See ADR-0008 for the precedent: "this is a bug fix restoring the intended behavior, not an architectural change.")
+- **"Cosmetic cleanup"** — formatting, indentation, import ordering, or local variable renaming with no semantic impact is direct implementation.
 
 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
+#### 3b. Route to the appropriate action
 
-Once classified, invoke the matching skill **inline** — execute it fully without stopping or returning control to the user:
+Once classified, take the matching action **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.
+- **Direct implementation** → tell the operator that no RFC or ADR is needed for this change, explain why (which Direct criterion applies), then **climb the minimality ladder** (see `_shared/fo-pipeline-conventions.md` §Minimality ladder) to determine the minimum implementation approach before writing any code. Present the ladder rung you landed on and proceed to implement. Do not create a governance document. The operator may still request an ADR for traceability if they prefer — respect that choice.
 
 Do not duplicate the creation skill's work — just route to it and let it run.
 
@@ -127,7 +151,7 @@ Do not duplicate the creation skill's work — just route to it and let it run.
 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)
+<Classified as in aiLanguage>: RFC (cross-workspace command addition) / ADR (local package convention) / Direct implementation (data fix or bug restore within existing contracts)
 ```
 
 Followed by the creation skill's own report.
@@ -231,7 +255,7 @@ After all documents are created, present a single batch report in `aiLanguage`.
 ## 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.
+- **Classify before acting.** Do not invoke a creation skill or start implementation until the classification is determined using the decision table in step 3a. Pick one path (RFC, ADR, or direct) based on the 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`.

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

@@ -125,6 +125,7 @@ This ecosystem is forward-only — no backward compatibility layers, no expand-t
 - **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`.
+- **NEEDS CLARIFICATION markers**: List all unresolved `NEEDS CLARIFICATION` markers with line numbers. If none are found, state "No unresolved markers." Markers in `draft` status are informational; markers in `reviewing`+ status are a blocking finding.
 
 #### Axis F — Pragmatism
 

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

@@ -49,6 +49,7 @@ Ask the user for, or infer from context:
 - **owners** — default `architecture`; confirm before using a different owner.
 - **commands.proposed / changed / removed** — any new, modified, or removed Site OS commands.
 - **packagesImpacted / appsImpacted** — concrete workspace names.
+- **liveSpec** — for feature-level RFCs (not governance/policy), suggest `liveSpec: true` to auto-derive a living spec domain from `packagesImpacted[0]`, or `liveSpec: <domain>` for an explicit domain. This enables automatic delta-merge into `docs/specs/live/<domain>.md` when the RFC is implemented.
 - **satisfies** — for `architecture` or `contract` RFCs, at least one `DNA-NN` invariant from `ref(forge.yaml bindings.paths.invariantsFile)`.
 - **related** — relevant RFCs, DNA ids, anti-patterns, specs.
 - **reviewer** — if the caller specifies a reviewer identity, use it. If not, default to `human:andrii-syrokomskyi` (matching the default in `os/rfc/rfc-0000-template.md` inside `@warpgogol/forge`) **only when the skill is also responsible for moving the RFC out of draft**. For a pure draft scaffold, leave `reviewers: []`.
@@ -90,6 +91,8 @@ Read the generated file and the full template (`os/rfc/rfc-0000-template.md` ins
 - **Acceptance criteria** — ≥3 checkable checkboxes mapped to implementation artifacts.
 - **Implementation notes for agents** — explicit MAY/MUST NOT rules, status-gate reminders, escalation triggers.
 
+When a section cannot be filled with confidence, insert `> NEEDS CLARIFICATION: <question>` instead of guessing. Do not leave sections empty or fill them with speculative content. Markers are resolved during the enhance step.
+
 ### 6. Validate and report
 
 Run:

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

@@ -73,9 +73,9 @@ Read the RFC's `status` frontmatter:
   rfc: revert RFC-XXXX to draft for enhancement
 
   Transition RFC-XXXX from reviewing to draft before enhance.
-  ```
+```
 
-  Stage only the RFC file. Then proceed with enhancement.
+Stage only the RFC file. Then proceed with enhancement.
 
 **No RFC may begin enhancement in any status other than `draft`.** The transition to `draft` is mandatory and must be committed before proceeding to step 4. (Terminal and accepted statuses are already filtered out in step 1.5.)
 
@@ -86,6 +86,7 @@ Read every finding from the audit report. For each, classify it as one of:
 - **Direct fix** — the RFC text can be edited to address it: fill a placeholder section, add a missing edge case, fix a DNA reference, tighten a contract, add a failure mode, etc.
 - **New RFC** — the finding reveals a topic that is too large or too distinct for this RFC. Examples: a new package, a new DNA invariant, a new governance policy, a new external contract. Splitting it out keeps the RFC focused and follows the ecosystem's one-decision-per-RFC principle.
 - **Out of scope** — the finding is valid but belongs to a different RFC or a future effort. Add it to this RFC's `nonGoals` with a brief explanation and, if applicable, a `related` reference to where it will be addressed.
+- **NC (Needs Clarification)** — Unresolved `NEEDS CLARIFICATION` markers in the RFC body. Resolution: ask the operator the question, replace the marker line with the operator's answer in the RFC body. If the operator defers, the marker remains and the RFC cannot transition to `reviewing`.
 
 Record the classification for every finding — the summary in step 8 reports it.
 

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

@@ -79,9 +79,9 @@ Execute the plan's step sequence in order. For each step:
    implement: RFC-XXXX step N — <step title>
 
    <one-line description of what was done in this step>.
-   ```
+```
 
-   Stage only the files touched by this step. Do not stage unrelated changes — another agent may be working in a different session.
+Stage only the files touched by this step. Do not stage unrelated changes — another agent may be working in a different session.
 
 **Implementation principles:**
 
@@ -151,6 +151,7 @@ Read the RFC's `## Acceptance criteria` section. For each checkbox:
 3. **If a criterion is not met**, implement the missing work, commit it, and re-verify.
 4. **Annotate every `[x]` with inline evidence** — add `(evidence: <file-path:line>, <test-or-command>)` to each checked criterion. This is enforced by V-27.
 5. **If a criterion cannot be met** (e.g., requires an external dependency not yet available, requires a pilot that is not registered), do NOT mark it `[x]` and do NOT stamp `implemented`. Instead, split the deferred work into a follow-up RFC via `rfc.supersede.propose`. An RFC with unchecked `[ ]` criteria cannot transition to `implemented` — this is enforced by V-26.
+6. **Ensure `reviewers` is non-empty** — `rfc.validate` enforces V-25: implemented RFCs with an empty `reviewers` field fail validation. Add at least one reviewer (e.g. `human:<name>`) before stamping `implemented`.
 
 Do not proceed to step 3.7 until every acceptance criterion checkbox is checked with evidence.
 
@@ -168,6 +169,8 @@ If the RFC was created on or after 2026-07-07 and has acceptance probes:
 ref(forge.yaml bindings.commands.validateRfc) --verification.emit --id RFC-XXXX
 ```
 
+**Note:** If acceptance probes are commented out (`# acceptance:`) in the RFC frontmatter, `rfc.verification.emit` silently skips creating an evidence file (`filesModified: []`, zero errors). This is expected behavior — RFCs with commented-out probes get no evidence file, and `rfc.implement.stamp` still works without it.
+
 Commit the evidence file:
 
 ```txt
@@ -183,7 +186,7 @@ Stage `docs/rfcs/verification/rfc-xxxx.generated.json`.
 Transition the RFC to `implemented` using the `rfc.implement.stamp` command. Direct edits to `status`, `implementedAt`, and `updatedAt` are prohibited for all actors.
 
 1. Ensure the working tree is clean (all implementation changes committed).
-2. Identify the implementation commit SHA — the commit that contains the core implementation work and references the RFC id in its message or changed files.
+2. Identify the implementation commit SHA — use the **first** `implement:` commit (the commit where implementation began), not the latest fix or documentation commit. Find it via `git log --oneline` and locate the first commit with an `implement:` prefix after the `plan:` or `rfc: accept` commit.
 3. Run the stamp command:
 
    ```sh
@@ -192,6 +195,8 @@ Transition the RFC to `implemented` using the `rfc.implement.stamp` command. Dir
 
    The command atomically validates all preconditions (accepted status, checked+evidenced criteria, clean tree, reachable RFC-referencing commit, passing probe evidence) and sets `status: implemented`, `implementedAt`, and `updatedAt` in one atomic write.
 
+   **Troubleshooting:** If the stamp fails with `Could not parse target RFC` (RFC-IMP-01), the RFC frontmatter has a YAML syntax error — not a missing file. Check for unquoted backtick values in `successSignals`, `nonGoals`, or other list items. YAML plain scalars starting with a backtick must be double-quoted.
+
 4. Commit the stamped RFC file:
 
    ```txt
@@ -314,7 +319,7 @@ If the ADR is already `accepted`, proceed directly.
 
 #### 4.3. Implement the decision
 
-Read the `## Decision` section and implement it in code. Follow the same principles as RFC implementation:
+Read the `## Decision` section and implement it in code. **For each decision point, verify whether the code already exists** — ADRs may declare fields or extensions that related RFCs did not fully implement. Do not assume associated RFCs covered everything; check each decision against the actual codebase and implement any gaps. Follow the same principles as RFC implementation:
 
 - Make autonomous, ecosystem-aligned decisions.
 - Use `edit`/`multi_edit` for changes to existing files, `write_to_file` for new files.

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

@@ -168,6 +168,16 @@ The grilling checks:
 
 Address every concern the grilling raises by revising the draft. Do not persist until the grilling is satisfied.
 
+### 5b. Summit suggestion
+
+If the RFC meets summit criteria (any of: `kind: architecture` AND `scope: workspace`, `satisfies[]` includes 2+ DNA invariants, introduces a new package/command/lifecycle, supersedes an implemented RFC), suggest using `fo-design-summit` before acceptance. Use `ask_user_question`:
+
+> "This RFC is complex (architecture, workspace scope, 2+ DNA invariants). Should I run a multi-persona design summit before acceptance?"
+
+Recommended option: "Run summit" — because complex RFCs benefit from multi-perspective review.
+
+If the operator declines, proceed to step 6. If the operator accepts, invoke `fo-design-summit` via the `skill` tool, wait for it to complete, then proceed to step 6.
+
 ### 6. Persist the plan
 
 Name the plan file by mirroring the RFC filename with a `plan-` prefix:

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

@@ -144,6 +144,11 @@ If the invariants file is absent or the optional binding is unresolvable, state
 
 #### Axis F — Pragmatism
 
+- **Minimality ladder**: the author climbed the minimality ladder (see `_shared/fo-pipeline-conventions.md` §Minimality ladder) before writing code. Flag cases where a lower rung was available but skipped:
+  - A new dependency was added for something stdlib or native platform features already provide (e.g. installing a date picker library when `<input type="date">` suffices).
+  - New code duplicates an existing utility, pattern, or function already in the codebase.
+  - A multi-line abstraction was written where a single line or existing API call would work.
+  - The code exists at all when the task didn't require it (YAGNI).
 - **Minimal command surface**: each new command earns its existence — no command that could be a flag on an existing command.
 - **Lean contracts**: TypeScript types are the minimum needed — no speculative generality, no unused optional fields.
 - **Existing patterns**: the diff checks whether an existing command, schema, or pattern can be extended before introducing a new one.

package/skills/fo/fo-session-retro/SKILL.md

@@ -25,9 +25,9 @@ Review the current session for discoveries that other agents would benefit from
 - **After exploring a new area** — when conventions or patterns were learned that are not yet documented.
 - **Inline by other skills** — `fo-doc-audit` or session-end workflows may delegate here for the "what did you learn?" step.
 
-### Session-end trigger phrases
+### Session-end trigger phrases (BLOCKED GATE — NON-NEGOTIABLE)
 
-When the operator says any of the following, invoke this skill via the `skill` tool BEFORE producing a closing summary:
+When the operator says any of the following, the agent's response is **BLOCKED** — no closing summary, no ad-hoc "session complete" message, no closing block is permitted until this skill is invoked via the `skill` tool and completes:
 
 - "Завершаем эту сессию"
 - "Завершаем сессию"
@@ -38,7 +38,9 @@ When the operator says any of the following, invoke this skill via the `skill` t
 - "Session end"
 - "/session-end"
 
-Do NOT produce a closing summary first — this skill IS the closing protocol. The skill's report is the session-end output. Do not add a separate "session complete" message.
+**The agent MUST NOT produce any session-end output (summary, closing block, "session complete" message) before this skill is invoked and its report is presented. Producing a closing summary without running this skill is a CONTRACT VIOLATION.**
+
+This skill IS the session-end protocol — it runs transcript save, temp cleanup, docs.archive, clean tree check, RFC verification, insight triage, and produces the closing block. Do not substitute it with a manual summary. The closing block comes from this skill's report, not from the agent directly.
 
 ## Step 0: Save session transcript (NON-NEGOTIABLE when saveSessions is true)
 
@@ -126,12 +128,14 @@ rtk git status --porcelain
 for d in missions/*/workpiece; do [ -d "$d/.git" ] && echo "=== $d ===" && rtk git -C "$d" status --porcelain; done
 ```
 
-**3b. Classify each dirty file as "ours" or "theirs":**
+**3b. Classify each dirty file as "ours" or "unattributed":**
 
-- A file is "ours" if EITHER:
+- A file is "ours" if ANY of:
   - You directly modified it via `edit`, `write_to_file`, `multi_edit`, or `edit_notebook` tools.
   - You indirectly modified it by running a command (`run_command`) that generates or updates it (e.g. codegen pipelines, build commands, etc.).
-- A file is "theirs" if it appears dirty but you have no record of touching it in this session. This means another parallel agent modified it. Do NOT commit, stash, or revert these files.
+  - It was produced by a session-end pipeline step in THIS session: session transcripts (`docs/sessions/*.md`), review reports (`docs/reviews/**/*.md`), or `docs.archive` moves.
+  - It was created by a skill you invoked in this session (e.g. `fo-review` creating a review report, `fo-doc-audit` editing AGENTS.md, `fo-idea-create-adr` creating an ADR).
+- A file is "unattributed" if it appears dirty but you have no record of touching it in this session. Do NOT assume it belongs to a parallel agent — it may be an orphan from a previous session that was not committed. The previous session-end protocol should have caught it, but if it didn't, this session must not propagate the problem further.
 
 **3c. Commit our changes:**
 
@@ -139,9 +143,12 @@ for d in missions/*/workpiece; do [ -d "$d/.git" ] && echo "=== $d ===" && rtk g
 - If there are "our" dirty files in a workpiece: `git -C missions/<missionId>/workpiece add <files>` and `git -C missions/<missionId>/workpiece commit -m "<descriptive message>"`.
 - Use descriptive commit messages that explain what the changes are, not just "session cleanup".
 
-**3d. Report remaining dirty files:**
+**3d. Handle unattributed dirty files (NON-NEGOTIABLE):**
 
-- If any dirty files remain after committing ours, report them to the operator: "The following files were modified by another agent and left untouched: <list>". Then proceed.
+- If any unattributed dirty files remain after committing ours, present them to the operator via `ask_user_question` (in `aiLanguage`) and ask whether to commit or leave each one untouched. Do NOT silently proceed — unattributed files are often orphans from previous sessions that must be resolved, not propagated.
+- For each unattributed file, the operator can choose:
+  - **Commit** — the agent stages and commits the file with a descriptive message.
+  - **Leave untouched** — the operator explicitly acknowledges the file should remain dirty (e.g. it belongs to a parallel agent still running).
 - If the tree is now clean (or was clean from the start), proceed silently.
 
 ### Step 4: RFC implementation verification (NON-NEGOTIABLE)