Scoville Plan

Scoville Plan

Maintain repository direction through direct Markdown and YAML edits. Preserve supported native format_version: 1 behavior: setup, read-only recovery, Plans, Work Items, Decisions, proposals, lifecycles, blockers, evidence, and narrow repair. Require no CLI, MCP server, database, journal, or hidden state; remove or reinterpret no project-knowledge feature.

A record does not prove work.

On explicit opt-out: read no references; do not create or change planning files; make no Skill-derived claims. Report any exact conflict with a higher-priority project instruction requiring this Plan system.

Ownership and limits

Precedence:

1. system, safety, and explicit current-request instructions;
2. repository instructions and their canonical planning mechanism;
3. an existing supported native profile;
4. these defaults for gaps.

Use the existing durable owner; never create a parallel Plan. Apply compatible guardrails only; runtime plans are disposable mirrors.

Never invoke a planning CLI. The optional bundled validator is strictly read-only and structural, never a write path. Claim no locking, atomic publication, typed mutation, or semantic proof; report observations only.

Family standalone: discovery != installed|active|applicable|required; absent|inactive => ignore/no require|install|simulate|reimplement; active+applicable => owner concern only, self continues; opt-out local. Owners: scoville-brainstorm divergence; scoville-code-anti-ai-slop engineering/proof; scoville-ui-anti-ai-slop interface/rendered proof; scoville-scribe-anti-ai-slop wording/fidelity; scoville-handoff transfer.

Plan owns wording and fidelity of its native records. If Scribe is installed, do not additionally activate, load, or apply it to their creation, rewriting, or wording audit. An explicit user request to use Scribe takes precedence for wording. Plan still owns permitted edits, format, and lifecycle unless opted out. If Scribe is active for another text segment, keep it scoped there. Plan works without Scribe and never requires its installation.

Choose planning and route references

Use a Plan for dependent outcomes, material sequencing, durable handoff, or a binding workflow. Implement one small reversible change directly unless the project requires a tracked Work Item.

Exact reference codes: R read-only.md; G planning-granularity.md; P native-plan-format.md; L native-project-lifecycle.md; E native-editing.md; W native-work-items.md; D native-decision-format.md; B native-decision-batches.md; V profile-validation.md.

Classify the operation and edited record, then load exactly its route. An edit inside a Work Item uses the Work Item route even though its file is a Plan.

For read-only, preload no format guides. If profile existence is unknown, list the root before canonical reads; never probe absent PROJECT_INDEX.md. For an explicitly requested new durable Plan, use the workspace as setup root, classify the whole profile, and initialize only if all three canonical paths are absent. Otherwise report absence. Preserve and stop on partial, foreign, unsupported, invalid, or intent-invalid state unless the route permits intent-preserving repair.

Preserve authority and lifecycle

Link each created Decision to every affected mutable Work Item.

A proposal request creates proposed; a clear request to record the stated choice authorizes acceptance. Reject, deprecate, supersede, activate, or cancel only with the explicit lifecycle choice required by the route. For an authorized multi-Decision accept-or-reject transition, use B and its helper route; never substitute single-transition or audit behavior.

At work start, inventory Decision frontmatter and read every proposal. Report ID/title/recommendation/effect; request accept|reject|revise. Repeat unresolved proposals at handoff; stop only dependent work.

Mark a Work Item done only after observing Acceptance and adding concise evidence. A captured structural-validation result supports only structural judgment and reporting, never acceptance evidence or mutation authority. Keep failed or partial work in_progress, paused, or explicitly blocked.

Keep behavior-complete work

• Split independently resumable outcomes when Acceptance, dependencies, ownership, or rollout timing differs. Put subordinate order in optional Steps. Put testing, review, documentation, and release checks in Acceptance or Evidence unless independently requested as resumable outcomes.
• Keep at most one Work Item in_progress, equal to current_item. This limits concurrency, not total Plan items.
• Change authored content or order only while todo. After start, preserve the starting approach and change only live state allowed by the route.
• Next action is the first unperformed concrete action. After implementation, advance to the first unobserved test, build, browser check, review, or evaluator-owned verification.
• Select current work only when dependencies are done and the successor is explicit. Use complete_and_advance only when completion and the exact replacement start form one valid prepared result.
• When final real work finishes, complete its Work Item and Plan and set the index idle. Never invent a successor to keep the Plan active.

Mutate narrowly and verify

Write compact records

Keep facts needed to choose, resume, verify, or revisit the work. Use direct sentences and compact bullets where the format permits. State each fact in its owning field, repeating it only when needed for correct interpretation. Remove filler, irrelevant chronology, and repeated rationale. Keep already concise text. Do not trade readability for abbreviations or long compressed sentences.

Before writing and during a wording audit, check that every sentence adds necessary information and that shortening preserves facts, constraints, alternatives, tradeoffs, uncertainty, exact identifiers, acceptance criteria, and evidence. Review only the requested scope. Brevity never authorizes changing immutable history, weakening Acceptance, or claiming unobserved verification. Report audit findings without editing. No fixed word or sentence count proves quality, and the structural validator does not perform this semantic check.

Apply and check edits

Before writing, confirm root, format, active Plan, current Work Item, affected bytes, outcome, and required acceptance evidence. Use context-bound patches; preserve unrelated work. Prepare and inspect the full multi-file result before applying any member.

After writing:

1. reread changed frontmatter and complete affected Work Item or Decision blocks;
2. inspect the scoped diff and check changed prose against the compact-record rules;
3. check index ownership, active-Plan count, current-item status, Work Item key order, dependency order and cycles, Decision and Plan references, blockers, lifecycle fields, Evidence, and Next action;
4. when its script and Python are already available, run the optional validator through V; otherwise perform and report the scoped manual inspection;
5. record only acceptance evidence observed for the mutation.

Use E's scoped-read rules: complete byte and structural checks need not print unchanged history. Widen reads when the operation or a diagnostic requires it.

During mutation, also stop on concurrent changes, ambiguous lifecycle authority, or a partial multi-file transition. Do not overwrite a problem into apparent validity.

Report durable state

Lead with Plan outcome. Name changed canonical files, active/blocked work, observed checks/evidence, unresolved choices, and next action. Distinguish native structural inspection from behavioral verification; omit routine file narration.