Ce Compound Refresh

Compound Refresh

Maintain the quality of docs/solutions/ over time. This workflow reviews existing learnings against the current codebase, then refreshes any derived pattern docs that depend on them.

Mode Detection

Check if $ARGUMENTS contains mode:headless. If present, strip it from arguments (use the remainder as a scope hint) and run in headless mode.

Headless mode rules

• Skip all user questions. Never pause for input.
• Process all docs in scope. No scope narrowing questions — if no scope hint was provided, process everything.
• Attempt all safe actions: Keep (no-op), Update (fix references), Consolidate (merge and delete subsumed doc), auto-Delete (unambiguous criteria met), Replace (when evidence is sufficient). If a write succeeds, record it as applied. If a write fails (e.g., permission denied), record the action as recommended in the report and continue — do not stop or ask for permissions.
• Mark as stale when uncertain. If classification is genuinely ambiguous (Update vs Replace vs Consolidate vs Delete) or Replace evidence is insufficient, mark as stale with status: stale, stale_reason, and stale_date in the frontmatter. If even the stale-marking write fails, include it as a recommendation.
• Use conservative confidence. In interactive mode, borderline cases get a user question. In headless mode, borderline cases get marked stale. Err toward stale-marking over incorrect action.
• Always generate a report. The report is the primary deliverable. It has two sections: Applied (actions that were successfully written) and Recommended (actions that could not be written, with full rationale so a human can apply them or run the skill interactively). The report structure is the same regardless of what permissions were granted — the only difference is which section each action lands in.

CONCEPTS.md bootstrap requests

If invoked specifically to create or bootstrap CONCEPTS.md (e.g., "create a CONCEPTS.md", "build the concept map", "set up shared vocabulary"), the intent is ambiguous between two jobs — building the vocabulary file and running a docs/solutions refresh — so disambiguate before proceeding. Use the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question. Two options:

1. Create CONCEPTS.md (build the concept map) — seed the repo-wide concept map and commit it; skip only the docs/solutions classification phases (Phases 0–4). Read references/concepts-vocabulary.md and follow its Seed goal and Scope of a seed (repo-wide) rules: seed the project's core domain nouns from the declared domain model (schema, core types, primary models, top-level domain docs), each meeting the qualifying bar, the codebase setting the count. Write the preamble (see Phase 4.5), cluster per the organization rules, and run the Discoverability Check so AGENTS.md/CLAUDE.md surface the new file. Then enter Phase 5 (Commit Changes) to commit/PR the new CONCEPTS.md and any instruction-file edit through the same durable-write flow the refresh uses — do not leave the bootstrap uncommitted. 2. Run a refresh cycle — proceed with the normal refresh flow below; CONCEPTS.md is seeded (if absent) and reconciled as part of Phase 4.5.

In headless mode there is no user to ask: default to the refresh cycle (vocabulary is seeded and reconciled within Phase 4.5 regardless) and note in the report that a standalone repo-wide bootstrap was not run.

Interaction Principles

These principles apply to interactive mode only. In headless mode, skip all user questions and apply the headless mode rules above.

Follow the same interaction style as ce-brainstorm:

• Ask questions one at a time — use the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to numbered options in plain text only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question
• Prefer multiple choice when natural options exist
• Start with scope and intent, then narrow only when needed
• Do not ask the user to make decisions before you have evidence
• Lead with a recommendation and explain it briefly

The goal is not to force the user through a checklist. The goal is to help them make a good maintenance decision with the smallest amount of friction.

Refresh Order

Refresh in this order:

1. Review the relevant individual learning docs first 2. Note which learnings stayed valid, were updated, were consolidated, were replaced, or were deleted 3. Then review any pattern docs that depend on those learnings

Why this order:

• learning docs are the primary evidence
• pattern docs are derived from one or more learnings
• stale learnings can make a pattern look more valid than it really is

If the user starts by naming a pattern doc, you may begin there to understand the concern, but inspect the supporting learning docs before changing the pattern.

Maintenance Model

For each candidate artifact, classify it into one of five outcomes:

Core Rules

1. Evidence informs judgment. The signals below are inputs, not a mechanical scorecard. Use engineering judgment to decide whether the artifact is still trustworthy. 2. Prefer no-write Keep. Do not update a doc just to leave a review breadcrumb. 3. Match docs to reality, not the reverse. When current code differs from a learning, update the learning to reflect the current code. The skill's job is doc accuracy, not code review — do not ask the user whether code changes were "intentional" or "a regression." If the code changed, the doc should match. If the user thinks the code is wrong, that is a separate concern outside this workflow. 4. Be decisive, minimize questions. When evidence is clear (file renamed, class moved, reference broken), apply the update. In interactive mode, only ask the user when the right action is genuinely ambiguous. In headless mode, mark ambiguous cases as stale instead of asking. The goal is automated maintenance with human oversight on judgment calls, not a question for every finding. 5. Avoid low-value churn. Do not edit a doc just to fix a typo, polish wording, or make cosmetic changes that do not materially improve accuracy or usability. 6. Use Update only for meaningful, evidence-backed drift. Paths, module names, related links, category metadata, code snippets, and clearly stale wording are fair game when fixing them materially improves accuracy. 7. Use Replace only when there is a real replacement. That means either:

• the current conversation contains a recently solved, verified replacement fix, or
• the user has provided enough concrete replacement context to document the successor honestly, or
• the codebase investigation found the current approach and can document it as the successor, or
• newer docs, pattern docs, PRs, or issues provide strong successor evidence.

8. Delete when the code is gone, and only after checking for inbound links. If the referenced code, controller, or workflow no longer exists in the codebase and no successor can be found, delete the file — don't default to Keep just because the general advice is still "sound." When in doubt between Keep and Delete, ask the user (in interactive mode) or mark as stale (in headless mode). Inbound links inform classification, not cleanup: cleanup is always mechanical, but decorative citations (principle stated inline) allow Delete, while substantive citations (citing doc relies on the cited doc) signal Replace. The auto-delete case is missing code, no matching successor, and citations absent or decorative. 9. Evaluate document-set design, not just accuracy. In addition to checking whether each doc is accurate, evaluate whether it is still the right unit of knowledge. If two or more docs overlap heavily, determine whether they should remain separate, be cross-scoped more clearly, or be consolidated into one canonical document. Redundant docs are dangerous because they drift silently — two docs saying the same thing will eventually say different things. 10. Delete, don't archive. There is no _archived/ directory. When a doc is no longer useful, delete it. Git history preserves every deleted file — that is the archive. A dedicated archive directory creates problems: archived docs accumulate, pollute search results, and nobody reads them. If someone needs a deleted doc, git log --diff-filter=D -- docs/solutions/ will find it.

Scope Selection

Start by discovering learnings and pattern docs under docs/solutions/.

Exclude:

• README.md
• docs/solutions/_archived/ (legacy — if this directory exists, flag it for cleanup in the report)

Find all .md files under docs/solutions/, excluding README.md files and anything under _archived/. If an _archived/ directory exists, note it in the report as a legacy artifact that should be cleaned up (files either restored or deleted).

If $ARGUMENTS is provided, use it to narrow scope before proceeding. Try these matching strategies in order, stopping at the first that produces results:

1. Directory match — check if the argument matches a subdirectory name under docs/solutions/ (e.g., performance-issues, database-issues) 2. Frontmatter match — search module, component, or tags fields in learning frontmatter for the argument 3. Filename match — match against filenames (partial matches are fine) 4. Content search — search file contents for the argument as a keyword (useful for feature names or feature areas)

If no matches are found, report that and ask the user to clarify. In headless mode, when a scope hint was provided but matched nothing, report the miss in the summary and exit without widening to all docs — do not silently fall back to processing everything. (The "process everything" rule from Headless mode rules applies only when no scope hint was provided.)

If no candidate docs are found, report:

No candidate docs found in docs/solutions/.
Run `ce-compound` after solving problems to start building your knowledge base.

Phase 0: Assess and Route

Before asking the user to classify anything:

1. Discover candidate artifacts 2. Estimate scope 3. Choose the lightest interaction path that fits

Route by Scope

Broad Scope Triage

When scope is broad (9+ candidate docs), do a lightweight triage before deep investigation:

1. Inventory — read frontmatter of all candidate docs, group by module/component/category 2. Impact clustering — identify areas with the densest clusters of learnings + pattern docs. A cluster of 5 learnings and 2 patterns covering the same module is higher-impact than 5 isolated single-doc areas, because staleness in one doc is likely to affect the others. 3. Spot-check drift — for each cluster, check whether the primary referenced files still exist. Missing references in a high-impact cluster = strongest signal for where to start. 4. Recommend a starting area — present the highest-impact cluster with a brief rationale and ask the user to confirm or redirect. In headless mode, skip the question and process all clusters in impact order.

Example:

Found 24 learnings across 5 areas.

The auth module has 5 learnings and 2 pattern docs that cross-reference
each other — and 3 of those reference files that no longer exist.
I'd start there.

1. Start with auth (recommended)
2. Pick a different area
3. Review everything

Do not ask action-selection questions yet. First gather evidence.

Phase 1: Investigate Candidate Learnings

For each learning in scope, read it, cross-reference its claims against the current codebase, and form a recommendation.

A learning has several dimensions that can independently go stale. Surface-level checks catch the obvious drift, but staleness often hides deeper:

• References — do the file paths, class names, and modules it mentions still exist or have they moved?
• Recommended solution — does the fix still match how the code actually works today? A renamed file with a completely different implementation pattern is not just a path update.
• Code examples — if the learning includes code snippets, do they still reflect the current implementation?
• Related docs — are cross-referenced learnings and patterns still present and consistent?
• Auto memory (Claude Code only) — does the injected auto-memory block in your system prompt contain entries in the same problem domain? Scan that block directly. If the block is absent, skip this dimension. A memory note describing a different approach than what the learning recommends is a supplementary drift signal.
• Overlap — while investigating, note when another doc in scope covers the same problem domain, references the same files, or recommends a similar solution. For each overlap, record: the two file paths, which dimensions overlap (problem, solution, root cause, files, prevention), and which doc appears broader or more current. These signals feed Phase 1.75 (Document-Set Analysis).
• Vocabulary — note domain terms the learning cites (entities, named processes, status concepts with project-specific meaning). For each term: does it appear in CONCEPTS.md? If yes, does the definition still match how the code uses the term? If no, flag the term for Phase 4.5 to add or bootstrap. Do not edit CONCEPTS.md during investigation — just collect the signal centrally.

Match investigation depth to the learning's specificity — a learning referencing exact file paths and code snippets needs more verification than one describing a general principle.

Drift Classification: Update vs Replace

The critical distinction is whether the drift is cosmetic (references moved but the solution is the same) or substantive (the solution itself changed):

• Update territory — file paths moved, classes renamed, links broke, metadata drifted, but the core recommended approach is still how the code works. ce-compound-refresh fixes these directly.
• Replace territory — the recommended solution conflicts with current code, the architectural approach changed, or the pattern is no longer the preferred way. This means a new learning needs to be written. A replacement subagent writes the successor following ce-compound's document format (frontmatter, problem, root cause, solution, prevention), using the investigation evidence already gathered. The orchestrator does not rewrite learnings inline — it delegates to a subagent for context isolation.

The boundary: if you find yourself rewriting the solution section or changing what the learning recommends, stop — that is Replace, not Update.

Memory-sourced drift signals are supplementary, not primary. A memory note describing a different approach does not alone justify Replace or Delete. Use memory signals to:

• Corroborate codebase-sourced drift (strengthens the case for Replace)
• Prompt deeper investigation when codebase evidence is borderline
• Add context to the evidence report ("(auto memory [claude]) notes suggest approach X may have changed since this learning was written")

In headless mode, memory-only drift (no codebase corroboration) should result in stale-marking, not action.

Judgment Guidelines

Three guidelines that are easy to get wrong:

1. Contradiction = strong Replace signal. If the learning's recommendation conflicts with current code patterns or a recently verified fix, that is not a minor drift — the learning is actively misleading. Classify as Replace. 2. Age alone is not a stale signal. A 2-year-old learning that still matches current code is fine. Only use age as a prompt to inspect more carefully. 3. Check for successors before deleting. Before recommending Replace or Delete, look for newer learnings, pattern docs, PRs, or issues covering the same problem space. If successor evidence exists, prefer Replace over Delete so readers are directed to the newer guidance.

Phase 1.5: Investigate Pattern Docs

After reviewing the underlying learning docs, investigate any relevant pattern docs under docs/solutions/patterns/.

Pattern docs are high-leverage — a stale pattern is more dangerous than a stale individual learning because future work may treat it as broadly applicable guidance. Evaluate whether the generalized rule still holds given the refreshed state of the learnings it depends on.

A pattern doc with no clear supporting learnings is a stale signal — investigate carefully before keeping it unchanged.

Phase 1.75: Document-Set Analysis

After investigating individual docs, step back and evaluate the document set as a whole. The goal is to catch problems that only become visible when comparing docs to each other — not just to reality.

Overlap Detection

For docs that share the same module, component, tags, or problem domain, compare them across these dimensions:

• Problem statement — do they describe the same underlying problem?
• Solution shape — do they recommend the same approach, even if worded differently?
• Referenced files — do they point to the same code paths?
• Prevention rules — do they repeat the same prevention bullets?
• Root cause — do they identify the same root cause?

High overlap across 3+ dimensions is a strong Consolidate signal. The question to ask: "Would a future maintainer need to read both docs to get the current truth, or is one mostly repeating the other?"

Supersession Signals

Detect "older narrow precursor, newer canonical doc" patterns:

• A newer doc covers the same files, same workflow, and broader runtime behavior than an older doc
• An older doc describes a specific incident that a newer doc generalizes into a pattern
• Two docs recommend the same fix but the newer one has better context, examples, or scope

When a newer doc clearly subsumes an older one, the older doc is a consolidation candidate — its unique content (if any) should be merged into the newer doc, and the older doc should be deleted.

Canonical Doc Identification

For each topic cluster (docs sharing a problem domain), identify which doc is the canonical source of truth:

• Usually the most recent, broadest, most accurate doc in the cluster
• The one a maintainer should find first when searching for this topic
• The one that other docs should point to, not duplicate

All other docs in the cluster are either:

• Distinct — they cover a meaningfully different sub-problem and have independent retrieval value. Keep them separate.
• Subsumed — their unique content fits as a section in the canonical doc. Consolidate.
• Redundant — they add nothing the canonical doc doesn't already say. Delete.

Retrieval-Value Test

Before recommending that two docs stay separate, apply this test: "If a maintainer searched for this topic six months from now, would having these as separate docs improve discoverability, or just create drift risk?"

Separate docs earn their keep only when:

• They cover genuinely different sub-problems that someone might search for independently
• They target different audiences or contexts (e.g., one is about debugging, another about prevention)
• Merging them would create an unwieldy doc that is harder to navigate than two focused ones

If none of these apply, prefer consolidation. Two docs covering the same ground will eventually drift apart and contradict each other — that is worse than a slightly longer single doc.

Cross-Doc Conflict Check

Look for outright contradictions between docs in scope:

• Doc A says "always use approach X" while Doc B says "avoid approach X"
• Doc A references a file path that Doc B says was deprecated
• Doc A and Doc B describe different root causes for what appears to be the same problem

Contradictions between docs are more urgent than individual staleness — they actively confuse readers. Flag these for immediate resolution, either through Consolidate (if one is right and the other is a stale version of the same truth) or through targeted Update/Replace.

Subagent Strategy

Use subagents for context isolation when investigating multiple artifacts — not just because the task sounds complex. Choose the lightest approach that fits:

When spawning any subagent, omit the mode parameter so the user's configured permission settings apply. Include this instruction in its task prompt:

Use dedicated file search and read tools (Glob, Grep, Read) for all investigation. Do NOT use shell commands (ls, find, cat, grep, test, bash) for file operations. This avoids permission prompts and is more reliable.

>

Also scan the "user's auto-memory" block injected into your system prompt (Claude Code only). Check for notes related to the learning's problem domain. Report any memory-sourced drift signals separately from codebase-sourced evidence, tagged with "(auto memory [claude])" in the evidence section. If the block is not present in your context, skip this check.

There are two subagent roles:

1. Investigation subagents — read-only. They must not edit files, create successors, or delete anything. Each returns: file path, evidence, recommended action, confidence, and open questions. These can run in parallel when artifacts are independent. 2. Replacement subagents — write a single new learning to replace a stale one. These run one at a time, sequentially (each replacement subagent may need to read significant code, and running multiple in parallel risks context exhaustion). The orchestrator handles all deletions and metadata updates after each replacement completes.

The orchestrator merges investigation results, detects contradictions, coordinates replacement subagents, and performs all deletions/metadata edits centrally. In interactive mode, it asks the user questions on ambiguous cases. In headless mode, it marks ambiguous cases as stale instead. If two artifacts overlap or discuss the same root issue, investigate them together rather than parallelizing.

Phase 2: Classify the Right Maintenance Action

After gathering evidence, assign one recommended action.

Keep

The learning is still accurate and useful. Do not edit the file — report that it was reviewed and remains trustworthy. Only add last_refreshed if you are already making a meaningful update for another reason.

Update

The core solution is still valid but references have drifted (paths, class names, links, code snippets, metadata). Apply the fixes directly.

Consolidate

Choose Consolidate when Phase 1.75 identified docs that overlap heavily but are both materially correct. This is different from Update (which fixes drift in a single doc) and Replace (which rewrites misleading guidance). Consolidate handles the "both right, one subsumes the other" case.

When to consolidate:

• Two docs describe the same problem and recommend the same (or compatible) solution
• One doc is a narrow precursor and a newer doc covers the same ground more broadly
• The unique content from the subsumed doc can fit as a section or addendum in the canonical doc
• Keeping both creates drift risk without meaningful retrieval benefit

When NOT to consolidate (apply the Retrieval-Value Test from Phase 1.75):

• The docs cover genuinely different sub-problems that someone would search for independently
• Merging would create an unwieldy doc that harms navigation more than drift risk harms accuracy

Consolidate vs Delete: If the subsumed doc has unique content worth preserving (edge cases, alternative approaches, extra prevention rules), use Consolidate to merge that content first. If the subsumed doc adds nothing the canonical doc doesn't already say, skip straight to Delete.

The Consolidate action is: merge unique content from the subsumed doc into the canonical doc, then delete the subsumed doc. Not archive — delete. Git history preserves it.

Replace

Choose Replace when the learning's core guidance is now misleading — the recommended fix changed materially, the root cause or architecture shifted, or the preferred pattern is different.

The user may have invoked the refresh months after the original learning was written. Do not ask them for replacement context they are unlikely to have — use agent intelligence to investigate the codebase and synthesize the replacement.

Evidence assessment:

By the time you identify a Replace candidate, Phase 1 investigation has already gathered significant evidence: the old learning's claims, what the current code actually does, and where the drift occurred. Assess whether this evidence is sufficient to write a trustworthy replacement:

• Sufficient evidence — you understand both what the old learning recommended AND what the current approach is. The investigation found the current code patterns, the new file locations, the changed architecture. → Proceed to write the replacement (see Phase 4 Replace Flow).
• Insufficient evidence — the drift is so fundamental that you cannot confidently document the current approach. The entire subsystem was replaced, or the new architecture is too complex to understand from a file scan alone. → Mark as stale in place:
• Add status: stale, stale_reason: [what you found], stale_date: YYYY-MM-DD to the frontmatter
• Report what evidence you found and what is missing
• Recommend the user run ce-compound after their next encounter with that area, when they have fresh problem-solving context

Delete

Choose Delete when:

• The code or workflow no longer exists and the problem domain is gone
• The learning is obsolete and has no modern replacement worth documenting
• The learning is fully redundant with another doc (use Consolidate if there is unique content to merge first)
• There is no meaningful successor evidence suggesting it should be replaced instead

Action: delete the file. No archival directory, no metadata — just delete it. Git history preserves every deleted file if recovery is ever needed.

Before deleting: check if the problem domain is still active

When a learning's referenced files are gone, that is strong evidence — but only that the implementation is gone. Before deleting, reason about whether the problem the learning solves is still a concern in the codebase:

• A learning about session token storage where auth_token.rb is gone — does the application still handle session tokens? If so, the concept persists under a new implementation. That is Replace, not Delete.
• A learning about a deprecated API endpoint where the entire feature was removed — the problem domain is gone. That is Delete.

Do not search mechanically for keywords from the old learning. Instead, understand what problem the learning addresses, then investigate whether that problem domain still exists in the codebase. The agent understands concepts — use that understanding to look for where the problem lives now, not where the old code used to be.

Before deleting: check for inbound links

A doc that other files cite is load-bearing in a way the doc itself does not announce. Before classifying as Delete, search the repo's markdown content (other docs, plans, instruction files, READMEs) for citations of the file — not source code, where citations are rare and only appear in comments. The filename slug is usually unique enough that one query covers all citation sites.

Search efficiently:

• Prefer the platform's native content-search tool (e.g., Grep in Claude Code) over shell. Drop to shell when materially better for the case.
• Search the filename slug (without .md); narrow to the full path only if matches are noisy.
• Read context lines around each match (e.g., Grep's -B/-A), not whole files.

Inbound links inform the classification, not the cleanup. Removing a citation is always mechanical (drop the parenthetical, the bare entry, or the deferring clause). The judgment is upstream: given these citations, is Delete still right, or is Replace closer to right?

Classify each citation by what it does in its citing context:

• Decorative — principle stated inline, citation is a "see also" pointer or bare attribution. Delete is fine; clean up citations in the same commit.
• Substantive — citing doc relies on the cited doc to provide content not stated inline (e.g., "see X for details on Y" with no inline Y). Signal Replace — write a successor at the same path, or Keep with narrowed scope if the doc's actual content is broader than its title implies.
• Mixed or unclear — stale-mark.

In headless mode, Delete + decorative cleanup is fine. Any substantive citation, or any genuine ambiguity, downgrades to stale-marking — writing a Replace successor is judgment-heavy and should not happen unattended.

Auto-delete only when all three hold:

• The implementation is gone (or fully superseded by a clearly better successor, or the doc is plainly redundant).
• The problem domain is gone — the app no longer deals with what the learning addresses.
• Inbound links are absent or unambiguously decorative.

If any condition fails, classify as Replace, Update, Consolidate, or stale-mark per the rules above. Do not delete a learning whose problem domain is still active or whose principles are cited substantively — fill the gap with a replacement instead.

Pattern Guidance

Apply the same five outcomes (Keep, Update, Consolidate, Replace, Delete) to pattern docs, but evaluate them as derived guidance rather than incident-level learnings. Key differences:

• Keep: the underlying learnings still support the generalized rule and examples remain representative
• Update: the rule holds but examples, links, scope, or supporting references drifted
• Consolidate: two pattern docs generalize the same set of learnings or cover the same design concern — merge into one canonical pattern
• Replace: the generalized rule is now misleading, or the underlying learnings support a different synthesis. Base the replacement on the refreshed learning set — do not invent new rules from guesswork
• Delete: the pattern is no longer valid, no longer recurring, or fully subsumed by a stronger pattern doc with no unique content remaining

Phase 3: Ask for Decisions

Headless mode

Skip this entire phase. Do not ask any questions. Do not present options. Do not wait for input. Proceed directly to Phase 4 and execute all actions based on the classifications from Phase 2:

• Unambiguous Keep, Update, Consolidate, auto-Delete, and Replace (with sufficient evidence) → execute directly
• Ambiguous cases → mark as stale
• Then generate the report (see Output Format)

Interactive mode

Most Updates and Consolidations should be applied directly without asking. Only ask the user when:

• The right action is genuinely ambiguous (Update vs Replace vs Consolidate vs Delete)
• You are about to Delete a document and the evidence is not unambiguous (see auto-delete criteria in Phase 2). When auto-delete criteria are met, proceed without asking.
• You are about to Consolidate and the choice of canonical doc is not clear-cut
• You are about to create a successor via Replace

Do not ask questions about whether code changes were intentional, whether the user wants to fix bugs in the code, or other concerns outside doc maintenance. Stay in your lane — doc accuracy.

Question Style

Always present choices using the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to numbered options in plain text only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.

Question rules:

• Ask one question at a time
• Prefer multiple choice
• Lead with the recommended option
• Explain the rationale for the recommendation in one concise sentence
• Avoid asking the user to choose from actions that are not actually plausible

Focused Scope

For a single artifact, present:

• file path
• 2-4 bullets of evidence
• recommended action

Then ask:

This [learning/pattern] looks like a [Keep/Update/Consolidate/Replace/Delete].

Why: [one-sentence rationale based on the evidence]

What would you like to do?

1. [Recommended action]
2. [Second plausible action]
3. Skip for now

Do not list all five actions unless all five are genuinely plausible.

Batch Scope

For several learnings:

1. Group obvious Keep cases together 2. Group obvious Update cases together when the fixes are straightforward 3. Present Consolidate cases together when the canonical doc is clear 4. Present Replace cases individually or in very small groups 5. Present Delete cases individually unless they are strong auto-delete candidates

Ask for confirmation in stages:

1. Confirm grouped Keep/Update recommendations 2. Then handle Consolidate groups (present the canonical doc and what gets merged) 3. Then handle Replace one at a time 4. Then handle Delete one at a time unless the deletion is unambiguous and safe to auto-apply

Broad Scope

If the user asked for a sweeping refresh, keep the interaction incremental:

1. Narrow scope first 2. Investigate a manageable batch 3. Present recommendations 4. Ask whether to continue to the next batch

Do not front-load the user with a full maintenance queue.

Phase 4: Execute the Chosen Action

For each candidate, execute the flow that matches its classification from Phase 2 (confirmed in Phase 3). Read references/per-action-flows.md and follow the matching section:

• Keep — no file edit by default; summarize why the learning remains trustworthy.
• Update — in-place edits when the solution is still substantively correct (path renames, link refreshes, module renames).
• Consolidate — merge overlapping docs into a canonical doc, delete subsumed docs, update cross-references. The orchestrator handles consolidation directly.
• Replace — write a successor learning via subagent (passing the documentation contract files), validate frontmatter, then delete the old. When evidence is insufficient, mark stale instead.
• Delete — final inbound-link check, then remove. Reclassify if late-discovered substantive citations surface.

Only one flow runs per candidate; the reference contains the per-action criteria, examples, and step-by-step instructions.

Phase 4.5: Vocabulary Capture

After the per-learning actions execute, aggregate the domain terms flagged across Phase 1's Vocabulary dimension and reconcile them with CONCEPTS.md.

First, read `references/concepts-vocabulary.md`. This is unconditional. Do not pre-judge from memory which Phase 1 signals qualify — the reference's criteria are non-obvious and a "nothing qualifies" judgment without reading is a shortcut, not a result.

Procedure:

1. Aggregate. Collect qualifying terms surfaced across the learnings in scope, applying the reference's criteria. If the same term surfaced in multiple learnings with different shades of precision, union the shades into one entry — not three entries, not most-recent-wins. 2. If `CONCEPTS.md` exists, add missing terms and refine existing entries when the corpus surfaced new precision. Do not duplicate entries already present. Then reconcile the in-scope core nouns: re-derive the core domain nouns of the area in scope from its declared model (per the Seed goal in the reference) and backfill any that are central but missing. This is the every-run safety net for stable-central terms that friction never surfaces — bounded to the area in scope, defining only terms investigated this run, never a repo-wide sweep. 3. If `CONCEPTS.md` does not exist and at least one qualifying term was surfaced, bootstrap it — and seed, don't write a single term. Alongside the surfaced term(s), seed the core domain nouns of the area in scope per the reference's Seed goal, so the file is anchored from creation rather than a lone peripheral entry (and so captured terms don't dangle against undefined siblings). The seed stays scoped to the area in scope — a repo-wide concept map comes only from the explicit bootstrap path above, not from a scoped refresh. At creation, hold the qualifying bar conservatively for borderline terms — a borderline term or a class/table/file name dressed up as an entity defers to a later run; clear core nouns are seeded, borderline ones wait. The conservatism is about quality, not count; updates to an existing file follow normal criteria. 4. Scope discipline and citation hygiene. Bootstrap, seed, and reconcile reflect only the area in scope — do not expand to other categories, and do not retroactively inject (see CONCEPTS.md) pointers into existing learnings. (The repo-wide bootstrap path above is the deliberate exception — it intentionally covers the whole declared model.) The report should note that additional entries are likely from refresh runs on other scopes. 5. Initial structure. When bootstrapping, start the file with this preamble under the # Concepts heading:

Shared domain vocabulary for this project — entities, named processes, and status concepts with project-specific meaning. Seeded with core domain vocabulary, then accretes as ce-compound and ce-compound-refresh process learnings; direct edits are fine. Glossary only, not a spec or catch-all.

Then add entries. Let term count drive shape: 1-4 terms → flat headings, more → cluster by domain relationship per the rules in references/concepts-vocabulary.md. 6. Scrub violations. Scan existing entries for content that violates references/concepts-vocabulary.md criteria — implementation specifics (file paths, class names, function signatures, code references), current-config values (thresholds, counts, enum values that will drift), status/owner/date metadata, duplicates of terms covered under a different name, or entries that lean on an undefined project-specific sibling (add the sibling or rephrase). Rewrite or consolidate. The full sweep is appropriate here because refresh is an audit; ce-compound's same-named phase scopes corrections to the coherence neighborhood of entries being touched.

If no Phase 1 signals qualified after applying the reference's criteria, record that outcome explicitly in the report's CONCEPTS.md line (e.g., "scanned, no qualifying terms"). Do not silently skip — the visible scan-and-no-result record is the audit signal that the reference was consulted.

Note: if this run creates CONCEPTS.md from scratch, the Discoverability Check below also surfaces it so future agents can discover it — by editing AGENTS.md/CLAUDE.md in interactive mode (with consent), or, in headless mode, by emitting a "Discoverability recommendation" line in the report rather than editing instruction files (per the headless boundary in step 4c — headless does doc maintenance, not project config). Either way the created file is surfaced or flagged for surfacing; subsequent runs skip this because the instruction file is already current or the recommendation was already reported.

Apply edits silently — no user prompt in any mode. Vocabulary capture is a side effect of refreshing, not a decision the user makes per run.

Output Format

The full report MUST be printed as markdown output. Do not summarize findings internally and then output a one-liner. The report is the deliverable — print every section in full, formatted as readable markdown with headers, tables, and bullet points.

After processing the selected scope, output the following report:

Compound Refresh Summary
========================
Scanned: N learnings

Kept: X
Updated: Y
Consolidated: C
Replaced: Z
Deleted: W
Skipped: V
Marked stale: S

CONCEPTS.md: <scanned, no qualifying terms | created with N entries (M seeded) | updated — N added, N refined, N reconciled, N scrubbed | repo-wide map created with N entries>

Then for EVERY file processed, list:

• The file path
• The classification (Keep/Update/Consolidate/Replace/Delete/Stale)
• What evidence was found -- tag any memory-sourced findings with "(auto memory [claude])" to distinguish them from codebase-sourced evidence
• What action was taken (or recommended)
• For Consolidate: which doc was canonical, what unique content was merged, what was deleted

For Keep outcomes, list them under a reviewed-without-edits section so the result is visible without creating git churn.

Headless mode report

In headless mode, the report is the sole deliverable — there is no user present to ask follow-up questions, so the report must be self-contained and complete. Print the full report. Do not abbreviate, summarize, or skip sections.

Split actions into two sections:

Applied (writes that succeeded):

• For each Updated file: the file path, what references were fixed, and why
• For each Consolidated cluster: the canonical doc, what unique content was merged from each subsumed doc, and the subsumed docs that were deleted
• For each Replaced file: what the old learning recommended vs what the current code does, and the path to the new successor
• For each Deleted file: the file path and why it was removed (problem domain gone, fully redundant, etc.)
• For each Marked stale file: the file path, what evidence was found, and why it was ambiguous

Recommended (actions that could not be written — e.g., permission denied):

• Same detail as above, but framed as recommendations for a human to apply
• Include enough context that the user can apply the change manually or re-run the skill interactively

If all writes succeed, the Recommended section is empty. If no writes succeed (e.g., read-only invocation), all actions appear under Recommended — the report becomes a maintenance plan.

Legacy cleanup (if docs/solutions/_archived/ exists):

• List archived files found and recommend disposition: restore (if still relevant), delete (if truly obsolete), or consolidate (if overlapping with active docs)

Phase 5: Commit Changes

After all actions are executed and the report is generated, handle committing the changes. Skip this phase if no files were modified (all Keep, or all writes failed).

Detect git context

Before offering options, check: 1. Which branch is currently checked out (main/master vs feature branch) 2. Whether the working tree has other uncommitted changes beyond what compound-refresh modified 3. Recent commit messages to match the repo's commit style

Headless mode

Use sensible defaults — no user to ask:

Stage only the files that compound-refresh modified — not other dirty files in the working tree.

Interactive mode

First, run git branch --show-current to determine the current branch. Then present the correct options based on the result. Stage only compound-refresh files regardless of which option the user picks.

If the current branch is main, master, or the repo's default branch:

1. Create a branch, commit, and open a PR (recommended) — the branch name should be specific to what was refreshed, not generic (e.g., docs/refresh-auth-learnings not docs/compound-refresh) 2. Commit directly to {current branch name} 3. Don't commit — I'll handle it

If the current branch is a feature branch, clean working tree:

1. Commit to {current branch name} as a separate commit (recommended) 2. Create a separate branch and commit 3. Don't commit

If the current branch is a feature branch, dirty working tree (other uncommitted changes):

1. Commit only the compound-refresh changes to {current branch name} (selective staging — other dirty files stay untouched) 2. Don't commit

Commit message

Write a descriptive commit message that:

• Summarizes what was refreshed (e.g., "update 3 stale learnings, consolidate 2 overlapping docs, delete 1 obsolete doc")
• Follows the repo's existing commit conventions (check recent git log for style)
• Is succinct — the details are in the changed files themselves

Relationship to ce-compound

• ce-compound captures a newly solved, verified problem
• ce-compound-refresh maintains older learnings as the codebase evolves — both their individual accuracy and their collective design as a document set

Use Replace only when the refresh process has enough real evidence to write a trustworthy successor. When evidence is insufficient, mark as stale and recommend ce-compound for when the user next encounters that problem area.

Use Consolidate proactively when the document set has grown organically and redundancy has crept in. Every ce-compound invocation adds a new doc — over time, multiple docs may cover the same problem from slightly different angles. Periodic consolidation keeps the document set lean and authoritative.

Discoverability Check

After the refresh report is generated, check whether the project's instruction files would lead an agent to discover and search docs/solutions/ before starting work in a documented area. This runs every time — the knowledge store only compounds value when agents can find it. If this check produces edits, they are committed as part of (or immediately after) the Phase 5 commit flow — see step 5 below.

1. Identify which root-level instruction files exist (AGENTS.md, CLAUDE.md, or both). Read the file(s) and determine which holds the substantive content — one file may just be a shim that @-includes the other (e.g., CLAUDE.md containing only @AGENTS.md, or vice versa). The substantive file is the assessment and edit target; ignore shims. If neither file exists, skip this check entirely. 2. Assess whether an agent reading the instruction files would learn three things:

• That a searchable knowledge store of documented solutions exists
• Enough about its structure to search effectively (category organization, YAML frontmatter fields like module, tags, problem_type)
• When to search it (before implementing features, debugging issues, or making decisions in documented areas — learnings may cover bugs, best practices, workflow patterns, or other institutional knowledge)

This is a semantic assessment, not a string match. The information could be a line in an architecture section, a bullet in a gotchas section, spread across multiple places, or expressed without ever using the exact path docs/solutions/. Use judgment — if an agent would reasonably discover and use the knowledge store after reading the file, the check passes.

3. If the spirit is already met, no action needed. 4. If not: a. Based on the file's existing structure, tone, and density, identify where a mention fits naturally. Before creating a new section, check whether the information could be a single line in the closest related section — an architecture tree, a directory listing, a documentation section, or a conventions block. A line added to an existing section is almost always better than a new headed section. Only add a new section as a last resort when the file has clear sectioned structure and nothing is even remotely related. b. Draft the smallest addition that communicates the three things. Match the file's existing style and density. The addition should describe the knowledge store itself, not the plugin.

Keep the tone informational, not imperative. Express timing as description, not instruction — "relevant when implementing or debugging in documented areas" rather than "check before implementing or debugging." Imperative directives like "always search before implementing" cause redundant reads when a workflow already includes a dedicated search step. The goal is awareness: agents learn the folder exists and what's in it, then use their own judgment about when to consult it.

Examples of calibration (not templates — adapt to the file):

When there's an existing directory listing or architecture section — add a line:

      docs/solutions/  # documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (module, tags, problem_type)

When nothing in the file is a natural fit — a small headed section is appropriate:

      ## Documented Solutions

      `docs/solutions/` — documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (`module`, `tags`, `problem_type`). Relevant when implementing or debugging in documented areas.

c. In interactive mode, explain to the user why this matters — agents working in this repo (including fresh sessions, other tools, or collaborators without the plugin) won't know to check docs/solutions/ unless the instruction file surfaces it. Show the proposed change and where it would go, then use the platform's blocking question tool to get consent before making the edit: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to presenting the proposal in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question. In headless mode, include it as a "Discoverability recommendation" line in the report — do not attempt to edit instruction files (headless scope is doc maintenance, not project config).

5. If `CONCEPTS.md` exists at repo root, run a parallel discoverability check for it. Use the same workflow as the docs/solutions/ check above: same target file, same edit-placement judgment, same consent-then-edit interaction shape per mode. Example calibration when a directory listing is present:

   CONCEPTS.md  # shared domain vocabulary — read when orienting to the codebase or before discussing domain concepts

Skip this step entirely if `CONCEPTS.md` does not exist — never nag for an artifact the project has not adopted. When skipped, this step produces no output and no edit.

6. Amend or create a follow-up commit when the check produces edits. If step 4 or step 5 resulted in an edit to an instruction file and Phase 5 already committed the refresh changes, stage the newly edited file and either amend the existing commit (if still on the same branch and no push has occurred) or create a small follow-up commit (e.g., docs: add docs/solutions/ discoverability to AGENTS.md, or docs: add CONCEPTS.md discoverability to AGENTS.md, or a combined message when both edits landed). If Phase 5 already pushed the branch to a remote (e.g., the branch+PR path), push the follow-up commit as well so the open PR includes the discoverability change. This keeps the working tree clean and the remote in sync at the end of the run. If the user chose "Don't commit" in Phase 5, leave the instruction-file edits unstaged alongside the other uncommitted refresh changes — no separate commit logic needed.

Resolution Templates

Choose the template matching the problem_type track (see references/schema.yaml).

---

Bug Track Template

Use for: build_error, test_failure, runtime_error, performance_issue, database_issue, security_issue, ui_bug, integration_issue, logic_error

<!-- YAML safety: array items (symptoms, applies_when, tags, related_components) starting with ` [ * & ! | > % @ ? or containing ": " must be wrapped in double quotes. See references/yaml-schema.md > "YAML Safety Rules". -->

---
title: [Clear problem title]
date: [YYYY-MM-DD]
category: [docs/solutions subdirectory]
module: [Module or area]
problem_type: [schema enum]
component: [schema enum]
symptoms:
  - [Observable symptom 1]
root_cause: [schema enum]
resolution_type: [schema enum]
severity: [schema enum]
tags: [keyword-one, keyword-two]
---

# [Clear problem title]

## Problem
[1-2 sentence description of the issue and user-visible impact]

## Symptoms
- [Observable symptom or error]

## What Didn't Work
- [Attempted fix and why it failed]

## Solution
[The fix that worked, including code snippets when useful]

## Why This Works
[Root cause explanation and why the fix addresses it]

## Prevention
- [Concrete practice, test, or guardrail]

## Related Issues
- [Related docs or issues, if any]

---

Knowledge Track Template

Use for: best_practice, documentation_gap, workflow_issue, developer_experience

<!-- YAML safety: array items (symptoms, applies_when, tags, related_components) starting with ` [ * & ! | > % @ ? or containing ": " must be wrapped in double quotes. See references/yaml-schema.md > "YAML Safety Rules". -->

---
title: [Clear, descriptive title]
date: [YYYY-MM-DD]
category: [docs/solutions subdirectory]
module: [Module or area]
problem_type: [schema enum]
component: [schema enum]
severity: [schema enum]
applies_when:
  - [Condition where this applies]
tags: [keyword-one, keyword-two]
---

# [Clear, descriptive title]

## Context
[What situation, gap, or friction prompted this guidance]

## Guidance
[The practice, pattern, or recommendation with code examples when useful]

## Why This Matters
[Rationale and impact of following or not following this guidance]

## When to Apply
- [Conditions or situations where this applies]

## Examples
[Concrete before/after or usage examples showing the practice in action]

## Related
- [Related docs or issues, if any]

CONCEPTS.md vocabulary rules

CONCEPTS.md defines the words that mean something specific in this codebase — substrate that docs/solutions/ and AGENTS.md can cite without redefinition. Lives at the repo root. Terms enter two ways — accretion and seeding (below) — and the file is created the first time either path produces a qualifying entry.

How terms enter: accretion and seeding

Two paths populate the file, and they cover different gaps:

• Accretion — a learning surfaces a term whose meaning wasn't obvious, so it gets defined. This reliably catches peripheral terms, because friction is what surfaces them.
• Seeding — a run proactively defines the core domain nouns of the area it is working in. This catches the stable-central terms accretion never reaches: the nouns a system is built around rarely break, so they rarely appear in a learning, yet they are exactly what a reader needs to orient. Without seeding, the file fills with peripheral mechanics and never names what the project is about.

Seed goal

Define the core domain nouns the area's declared domain model exposes that meet the qualifying bar (see "What earns a slot"). The codebase sets the count: seed every term that genuinely qualifies, none added to reach a number and none pulled from beyond the declared model to inflate one. A small domain yields a few; a large one, more. The bound is the source (the declared domain model of the area in scope — schema, core types, primary models, top-level domain docs — not a full-codebase trawl) and the bar (the same "a new engineer would need this defined" test), never a fixed quantity.

Scope of a seed

• A scoped run — a learning capture, or a refresh narrowed to an area — seeds only that area's core nouns, and defines only terms it actually investigated against code. It does not reach for repo-wide nouns it never touched.
• A repo-wide bootstrap — an explicit "create CONCEPTS.md" request — seeds the whole project's declared domain model. This is the only path that produces a coherent "what is this project" glossary; a scoped run cannot, and should not pretend to.

Be opinionated

When the team uses several words for the same concept, pick the best one and retire the rest. Record retired synonyms as aliases on the entry (see "Per entry"). Settled distinctions go to the Flagged ambiguities tail. The glossary is not a record of all words the team has ever used — it is the team's agreed-upon vocabulary.

The file stands on its own

Each entry teaches its concept to a reader with no access to anything else — no codebase, no PR history, no architecture meetings, no Slack. This rules out:

• Implementation specifics (file paths, class names, function signatures, table names, library calls)
• Status fields, dates, owners on the entries
• Examples or current-config values drawn from the code — specific thresholds, counts, or enum values that will change. State the behavior, not the number: "each skill sets its own actionable threshold" rather than "surfaces at 50, fixes at 75."
• Links to PRs, issues, channels, or roadmap milestones
• Version-specific claims ("currently uses X; migrating to Y")

Cross-references between entries within CONCEPTS.md are fine — they resolve internally. General programming vocabulary (caches, queues, jobs, sessions) and everyday domain English need no redefinition either. But if an entry leans on another project-specific term to make sense, that term must be defined here too — an undefined project-specific sibling is itself a candidate to add.

What earns a slot

A term qualifies when its meaning here is precise enough that a new engineer would need it defined to follow conversations, tickets, or code. General programming vocabulary does not belong, even when used heavily.

Per entry

Definition is one sentence — what the term means in this domain, what makes it distinct from neighbors. A term with non-obvious behavioral rules (lifecycle, cancellation semantics, ownership invariants) earns a second paragraph for those rules — never for elaborating the definition itself.

When retired synonyms exist, list them as an aliases line directly under the definition: Avoid: Booking, appointment. Entities typically need more depth than value types; status concepts may need transition notes.

Relationships (optional)

When relationships between entries carry load-bearing meaning (ownership, cardinality, lifecycle dependencies that span entries), capture them in a ## Relationships section near the top of the file or its cluster. Skip when entries stand on their own without structural context — relationships are a lift for domains where structure is part of what makes terms meaningful, not a routine section.

Organization

Cluster concepts by domain relationship — entities with their states, processes with their stages — so a reader sees structure without effort. A flat list works when the file is small. Reshape as the file grows.

Flagged ambiguities (tail of file)

When two terms were used interchangeably and the team settled on a distinction, record the resolution as a one-line note: "'account' had been used for both Customer and User — these are distinct." This section is the audit trail for opinions the team has formed.

One illustrative entry — the shape, not a template

## Booking

### Reservation
A future commitment to seat a Party at a specified date and time.
*Avoid:* Booking, appointment

A Reservation owns its Party but does not own a Table — Tables are acquired only when the Party arrives, through a Seating. Lifecycle: Booked, Seated, Completed, No-Show. Cancellation before a Seating is non-destructive; cancellation after a Seating is recorded as a No-Show.

### Party
The guests committed to a Reservation. Each Reservation has exactly one Party. Party size is the count promised at booking, not the count who arrive.

### Table
A physical seating unit with fixed capacity. Tables are shared resources — they do not belong to Reservations and are allocated only on the day-of through Seatings.

### Seating
The act of placing a Party at a Table once the Party arrives. A Reservation has at most one Seating; a Table accumulates many Seatings across its lifetime.

Per-Action Flows

Read this reference when executing Phase 4. Find the section matching the action classified in Phase 2 and confirmed in Phase 3 (Keep, Update, Consolidate, Replace, or Delete) and follow that flow.

Keep Flow

No file edit by default. Summarize why the learning remains trustworthy.

Update Flow

Apply in-place edits only when the solution is still substantively correct.

Examples of valid in-place updates:

• Rename app/models/auth_token.rb reference to app/models/session_token.rb
• Update module: AuthToken to module: SessionToken
• Fix outdated links to related docs
• Refresh implementation notes after a directory move

Examples that should not be in-place updates:

• Fixing a typo with no effect on understanding
• Rewording prose for style alone
• Small cleanup that does not materially improve accuracy or usability
• The old fix is now an anti-pattern
• The system architecture changed enough that the old guidance is misleading
• The troubleshooting path is materially different

Those cases require Replace, not Update.

Consolidate Flow

The orchestrator handles consolidation directly (no subagent needed — the docs are already read and the merge is a focused edit). Process Consolidate candidates by topic cluster. For each cluster identified in Phase 1.75:

1. Confirm the canonical doc — the broader, more current, more accurate doc in the cluster. 2. Extract unique content from the subsumed doc(s) — anything the canonical doc does not already cover. This might be specific edge cases, additional prevention rules, or alternative debugging approaches. 3. Merge unique content into the canonical doc in a natural location. Do not just append — integrate it where it logically belongs. If the unique content is small (a bullet point, a sentence), inline it. If it is a substantial sub-topic, add it as a clearly labeled section. 4. Update cross-references — if any other docs reference the subsumed doc, update those references to point to the canonical doc. 5. Delete the subsumed doc. Do not archive it, do not add redirect metadata — just delete the file. Git history preserves it.

If a doc cluster has 3+ overlapping docs, process pairwise: consolidate the two most overlapping docs first, then evaluate whether the merged result should be consolidated with the next doc.

Structural edits beyond merge: Consolidate also covers the reverse case. If one doc has grown unwieldy and covers multiple distinct problems that would benefit from separate retrieval, it is valid to recommend splitting it. Only do this when the sub-topics are genuinely independent and a maintainer might search for one without needing the other.

Replace Flow

Process Replace candidates one at a time, sequentially. Each replacement is written by a subagent to protect the main context window.

When a replacement is needed, read the documentation contract files and pass their contents into the replacement subagent's task prompt:

• references/schema.yaml — frontmatter fields and enum values
• references/yaml-schema.md — category mapping
• assets/resolution-template.md — section structure

Do not let replacement subagents invent frontmatter fields, enum values, or section order from memory.

When evidence is sufficient:

1. Spawn a single subagent to write the replacement learning. Pass it:

• The old learning's full content
• A summary of the investigation evidence (what changed, what the current code does, why the old guidance is misleading)
• The target path and category (same category as the old learning unless the category itself changed)
• The relevant contents of the three support files listed above

2. The subagent writes the new learning using the support files as the source of truth: references/schema.yaml for frontmatter fields and enum values, references/yaml-schema.md for category mapping and YAML-safety rules for array items, and assets/resolution-template.md for section order. It should use dedicated file search and read tools if it needs additional context beyond what was passed. 3. Validate parser-safety of the new learning's frontmatter to catch silent-corruption issues the prose rules miss: malformed --- delimiter lines, unquoted # in scalar values (silent comment truncation), and unquoted : in scalar values (silent mapping confusion). The bundled validator ships inside the skill bundle; on Claude Code ${CLAUDE_SKILL_DIR} resolves to the skill directory, but the runtime Bash tool's CWD is the user's project, so a project-relative path (without the ${CLAUDE_SKILL_DIR} prefix) would miss. Run it through an existence guard so platforms that cannot locate the script (e.g. native Codex/Gemini installs, where ${CLAUDE_SKILL_DIR} is unset) fall back to a manual check instead of silently skipping the protection:

   if [ -n "${CLAUDE_SKILL_DIR}" ] && [ -f "${CLAUDE_SKILL_DIR}/scripts/validate-frontmatter.py" ]; then
     python3 "${CLAUDE_SKILL_DIR}/scripts/validate-frontmatter.py" <new-learning-path>
   else
     echo "Bundled validate-frontmatter.py not resolvable on this platform; applying the parser-safety checklist manually."
   fi

• If the script ran: exit 0 means parser-safe; exit 1 means stderr names the offending field(s) — quote the value(s), re-write the doc, and re-run until exit 0. Do not declare success while validation fails.
• If the script did not run (else branch): apply the validator's checks by hand, matching its exact scope — checking more broadly risks edits the validator would not require. Fix any violation by quoting the whole value before continuing:

1. The opening and closing frontmatter delimiters are each a line whose content is --- (trailing whitespace is fine; ---- or ---extra is not a valid delimiter). 2. For each top-level mapping entry (key: value, no leading indentation) whose value is not already quoted or structured (does not start with ", ', [, {, |, or >): the value must contain no unquoted # (space-then-hash — YAML treats it as a comment and silently truncates) and no unquoted : (colon-then-space — strict YAML may read it as a nested mapping). Quote the whole value if either appears. Nested values, array items, and already-quoted values are out of scope here (array-item quoting is handled by the schema/YAML-safety step above). Then note in the completion output that the bundled script validator was unavailable on this platform and the checks were applied manually.

The validator does not enforce schema rules and does not flag YAML reserved-indicator characters (those produce loud parser errors downstream rather than silent corruption — out of scope). Uses Python 3 stdlib only (no PyYAML or other deps). 4. After the subagent completes, the orchestrator deletes the old learning file. The new learning's frontmatter may include supersedes: [old learning filename] for traceability, but this is optional — the git history and commit message provide the same information.

When evidence is insufficient:

1. Mark the learning as stale in place:

• Add to frontmatter: status: stale, stale_reason: [what you found], stale_date: YYYY-MM-DD

2. Report what evidence was found and what is missing 3. Recommend the user run ce-compound after their next encounter with that area

Delete Flow

Delete only when a learning is clearly obsolete, redundant (with no unique content to merge), or its problem domain is gone. Do not delete a document just because it is old — age alone is not a signal.

Before unlinking the file, run a final inbound-link check across the repo's markdown content to catch any references missed during Phase 1 investigation. Prefer the platform's native content-search tool (e.g., Grep in Claude Code) for efficiency; use ranged or context-line reads around matches rather than loading whole files.

Each match is a citation that will dangle after delete. Cleanup is mechanical — Phase 2 already classified the citations and confirmed Delete was right. Don't re-litigate.

If any citation surfaces here that wasn't seen in Phase 1 and is anything other than unambiguously decorative (substantive or mixed/unclear), stop and reclassify: autofix mode stale-marks; interactive mode asks the user whether Replace fits. Only proceed with cleanup when all late-discovered citations are unambiguously decorative.

YAML Frontmatter Schema

schema.yaml in this directory is the canonical contract for docs/solutions/ frontmatter written by ce-compound.

Use this file as the quick reference for:

• required fields
• enum values
• validation expectations
• category mapping
• track classification (bug vs knowledge)

Tracks

The problem_type determines which track applies. Each track has different required and optional fields.

Required Fields (both tracks)

• module: Module or area affected
• date: ISO date in YYYY-MM-DD
• problem_type: One of the values listed in the Tracks table above
• component: One of rails_model, rails_controller, rails_view, service_object, background_job, database, frontend_stimulus, hotwire_turbo, email_processing, brief_system, assistant, authentication, payments, development_workflow, testing_framework, documentation, tooling
• severity: One of critical, high, medium, low

Bug Track Fields

Required:

• symptoms: YAML array with 1-5 observable symptoms (errors, broken behavior)
• root_cause: One of missing_association, missing_include, missing_index, wrong_api, scope_issue, thread_violation, async_timing, memory_leak, config_error, logic_error, test_isolation, missing_validation, missing_permission, missing_workflow_step, inadequate_documentation, missing_tooling, incomplete_setup
• resolution_type: One of code_fix, migration, config_change, test_fix, dependency_update, environment_setup, workflow_improvement, documentation_update, tooling_addition, seed_data_update

Knowledge Track Fields

No additional required fields beyond the shared ones. All fields below are optional:

• applies_when: Conditions or situations where this guidance applies
• symptoms: Observable gaps or friction that prompted this guidance
• root_cause: Underlying cause, if there is a specific one
• resolution_type: Type of change, if applicable

Optional Fields (both tracks)

• related_components: Other components involved
• tags: Search keywords, lowercase and hyphen-separated

Optional Fields (bug track only)

• rails_version: Rails version in X.Y.Z format

Backward Compatibility

Docs created before the track system may have symptoms/root_cause/resolution_type on knowledge-type problem_types. These are valid legacy docs:

• Bug-track fields present on a knowledge-track doc are harmless. Do not strip them during refresh unless the doc is being rewritten for other reasons.
• When creating new docs, follow the track rules above.

Category Mapping

• build_error -> docs/solutions/build-errors/
• test_failure -> docs/solutions/test-failures/
• runtime_error -> docs/solutions/runtime-errors/
• performance_issue -> docs/solutions/performance-issues/
• database_issue -> docs/solutions/database-issues/
• security_issue -> docs/solutions/security-issues/
• ui_bug -> docs/solutions/ui-bugs/
• integration_issue -> docs/solutions/integration-issues/
• logic_error -> docs/solutions/logic-errors/
• developer_experience -> docs/solutions/developer-experience/
• workflow_issue -> docs/solutions/workflow-issues/
• best_practice -> docs/solutions/best-practices/
• documentation_gap -> docs/solutions/documentation-gaps/
• architecture_pattern -> docs/solutions/architecture-patterns/
• design_pattern -> docs/solutions/design-patterns/
• tooling_decision -> docs/solutions/tooling-decisions/
• convention -> docs/solutions/conventions/

Validation Rules

1. Determine the track from problem_type using the Tracks table. 2. All shared required fields must be present. 3. Bug-track required fields (symptoms, root_cause, resolution_type) must be present on bug-track docs. 4. Knowledge-track docs have no additional required fields beyond the shared ones. 5. Bug-track fields on existing knowledge-track docs are harmless (see Backward Compatibility). 6. Enum fields must match the allowed values exactly. 7. Array fields must respect min/max item counts. 8. date must match YYYY-MM-DD. 9. rails_version, if present, must match X.Y.Z and only applies to bug-track docs.

YAML Safety Rules

Strict YAML 1.2 parsers (yq, js-yaml strict, PyYAML) reject array items that start with a reserved indicator character as unquoted scalars. When writing items for any array-of-strings field (symptoms, applies_when, tags, related_components, or any future array field), wrap the value in double quotes if it starts with any of:

` `, [, *, &, !, |, >, %, @, ?`

Also quote if the value contains the substring ": " — that punctuation confuses flow-style parsers.

Example — before (breaks strict YAML):

symptoms:

• sudo dscacheutil -flushcache does not restore in-container mDNS

Example — after (parses cleanly):

symptoms:

• "sudo dscacheutil -flushcache does not restore in-container mDNS"

This rule applies to all array-of-strings frontmatter fields. Scalar string fields like description: have their own quoting rules (see plugin AGENTS.md under "YAML Frontmatter").