Skip to content

Anuva Development Policy Phase 4 Implementation Plan

Status

Status: Phase 4 complete. Implementation PR #27 merged reviewed head 610f3671c54f23187c02a6eb7b2d6c54f94d5491 as merge commit 7773e5db744e94a3ede35482c939210701f70527 on 2026-07-30. The user approved this exact plan after Phase 3 completion. Phase 3 implementation PR #25 merged as a02084cc9628973f5a965512a48486ba51c979eb, and its focused completion-status PR #26 merged as f93461318639d19bc90b844d60de53902d580c8c.

The approved Gate 1 source replaces the readiness-only plugin with version 0.2.0, twelve skills, three bundled references, and deterministic contract tests. Focused plugin tests pass with 16 tests and 148 assertions. The full Product Main check passes with 118 tests and 467 assertions plus typechecking. Packaged skill validation and strict documentation verification pass. All checked-in compatibility skills remain unchanged, and every implementation repository retains its baseline commit and Git state. Gate 2 installed version 0.2.0, recreated and discovered 0.1.0 from merged main, returned to the exact Gate 1 commit, and passed the five-repository acceptance matrix.

The Python validators supplied by the authoring skills were attempted but their runtime lacks PyYAML. No temporary dependency was installed. The packaged Anuva validator uses the repository's bundled JavaScript YAML dependency.

No Linear mutation, sibling write, checked-in skill removal, CLI or toolchain mutation, or Cloudflare mutation occurred. Only the reviewed Product Main implementation PR was readied and merged at Gate 3.

Gate 1 source evidence

The implementation contains:

  • plugin manifest version 0.2.0 and exactly twelve skill directories;
  • three versioned references for process policy, repository verification, and toolchain/environment boundaries;
  • issue-free routine and material repository classification with optional Linear only when explicitly requested;
  • an explicit-only, Linear-free development-process workflow;
  • explicit-only environment and toolchain workflows;
  • direct keyring-capable GitHub authentication guidance;
  • no app, MCP server, hook, custom UI, script bundle, or arbitrary executor; and
  • exact tests for catalog, metadata, references, lane boundaries, approvals, repository precedence, preview behavior, and machine gates.

Gate 1 verification passes:

  • focused plugin validation: 16 tests and 148 assertions;
  • full Product Main check: 118 tests and 467 assertions plus typechecking;
  • packaged source and installed-cache skill validation;
  • strict served-page verification for all thirteen changed documentation pages;
  • unchanged Product Main compatibility skills and marketplace entry; and
  • unchanged baseline commits and Git state in Bento, CMS, Python, and Unity.

Gate 2 live evidence

Gate 2 used Product Main commit 2f2cd6349d42a2689b9006d9c390f54567df34d1. Its durable committed plugin Git tree identity is 13af45f55514554ba262038dccd5c81986b13da9.

The raw pre-installation working-tree hashes presented for Gate 2 approval were:

  • manifest SHA-256 e4781ba9ee77a6c1125d2a9476b0e9ee3e7833eb723671fe73dd2875208ebfb5; and
  • plugin tree SHA-256 d3e77b3a4fc2b4ee2779cd5ae6bd439d3373bcb952b61c153918002e62a31362.

The approved rollback branch switches caused Git for Windows to rewrite text working-tree line endings without changing the commit or Git tree. The final checked-out 0.2.0 source and installed cache are byte-identical at raw tree SHA-256 a2b6ab32b7392db0a04b693132cdc545ae357251cedabc7e054365373c72e740; the checked-out raw manifest SHA-256 is 3bdafe38a3dfbd76a8ddc69e0a999152f0895a491ac3ce5e0f6739408476a050. The user approved this focused evidence-identity amendment. Git tree identity is the durable source comparison; raw hashes describe the exact checkout and package bytes at their recorded gate.

The Codex plugin page manages one active cache for this local marketplace. Its first reinstall selected 0.2.0 and evicted 0.1.0, so work stopped at the planned recovery boundary. The user approved a focused amendment making merged main commit f93461318639d19bc90b844d60de53902d580c8c and its 0.1.0 plugin source the durable rollback target rather than requiring simultaneous cache retention.

The amended sequence passed:

  1. clean merged main recreated cache 0.1.0;
  2. a fresh read-only Codex process discovered $anuva-development:anuva-development-readiness, policy version 0.1, and all eight checked-in Product Main compatibility skills;
  3. the exact Gate 1 commit recreated cache 0.2.0;
  4. a fresh process discovered the nine implicit skills and an explicit $anuva-development:anuva-development-process-change invocation loaded the explicit-only skill from the installed cache; and
  5. Product Main, Bento, CMS, Python, and Unity passed their exact read-only classification and explicit-skill scenarios.

The final machine state has anuva-development@anuva enabled with active cache 0.2.0. No cache or Codex configuration was edited by hand.

Gate 3 merge evidence

Gate 3 reviewed draft PR #27 at exact head 610f3671c54f23187c02a6eb7b2d6c54f94d5491. It was mergeable with no reviews, comments, review threads, or reported GitHub checks. The user approved that exact head, which merged as 7773e5db744e94a3ede35482c939210701f70527.

Local main was fast-forwarded to the merge commit. The local and remote codex/development-policy-phase-4 branches were deleted only after the reviewed head was confirmed as an ancestor of merged main. Post-merge packaged skill validation and strict documentation verification passed. The installed source and cache remained byte-identical, and all eight checked-in compatibility skills remained present.

Phase 5 planning and implementation have not started.

Outcome

Phase 4 replaces the Phase 1 readiness-only plugin source with a reviewed skills-only anuva-development plugin version 0.2.0 that:

  • distributes the shared Product Main, repository, documentation, development-process, environment, and toolchain skills;
  • applies the policy's five work lanes and risk-based approval gates;
  • keeps Product Main Linear planning for product changes and shared application contracts;
  • makes routine and material single-repository work issue-free by default;
  • keeps standalone Linear tracking available only when the user explicitly requests durable tracking;
  • makes development-process work an explicit Product Main workflow with no Linear issue;
  • uses repository AGENTS.md files for product boundaries and affected-scope verification;
  • uses the installed plugin-qualified identity for acceptance testing;
  • checks GitHub authentication directly in the known keyring-capable context before GitHub-backed delivery instead of deliberately failing first in the sandbox; and
  • remains skills-only, with no app, MCP server, hook, custom UI, workflow engine, or arbitrary command surface.

Phase 4 validates the plugin while all checked-in shared skill copies remain available. Updating implementation-repository instructions, moving repository-specific verification, removing checked-in copies, and proving unqualified natural-language routing after removal remain Phase 5.

Baseline

The approved baseline is:

  • Product Main main: f93461318639d19bc90b844d60de53902d580c8c;
  • installed Anuva CLI: 0.2.1-g3dd30bca40f1;
  • installed CLI previous target: 0.2.0-gc8776c067168;
  • plugin source version: 0.1.0;
  • verified plugin cache: %USERPROFILE%\.codex\plugins\cache\anuva\anuva-development\0.1.0;
  • installed plugin source skills: anuva-development-readiness only;
  • Product Main checked-in compatibility skills: eight, all present; and
  • local marketplace: anuva, registered from the Product Main repository root with anuva-development@anuva enabled.

Read-only inventory found that Bento, CMS, Python, and Unity each contain the six implementation-repository shared skill identities, including linear-list-ready-issues. Repository-change and Linear-validation copies are mostly identical, while implementation, review, and some preview copies contain repository-specific differences. Those differences are inputs to the bundled verification matrix; they are not copied wholesale into shared plugin procedure.

Scope boundary

Included

  • Product Main plugin source under plugins/anuva-development.
  • Plugin version, interface prompt, twelve shared skills, UI metadata, and three bundled references.
  • Product Main unit tests for plugin structure, skill contracts, references, compatibility retention, and cache validation.
  • Product Main development and engineering documentation needed to describe the Phase 4 plugin contract and the compatibility period.
  • A local machine-one plugin upgrade, rollback, inverse rollback, and fresh-task acceptance only after a separate Gate 2 approval of the exact committed source and effects.
  • Read-only fresh-task acceptance from Product Main, Bento, CMS, Python, and Unity.
  • A focused Product Main draft PR after source validation.

Excluded

  • Linear issue creation, mutation, or completion.
  • Changes to Bento, CMS, Python, or Unity files or Git state.
  • Product implementation, schemas, migrations, authentication or authorization, privacy, security, billing, deployment architecture, application contracts, runtime assets, packages, or releases.
  • Removal or modification of any checked-in shared skill under .agents/skills/anuva in any repository.
  • Migration of any repository AGENTS.md, prompt, bootstrap page, or active unqualified skill reference; that remains Phase 5.
  • Codex rule-file changes; that remains Phase 6.
  • Anuva CLI source, build, installation, upgrade, rollback, toolchain bootstrap, or command-surface changes.
  • Cloudflare tunnel, route, DNS, certificate, Access policy, token, or canonical documentation publication changes.
  • Manual deletion of plugin caches.
  • An MCP server, hook, app, custom UI, central process-sync workflow, YAML workflow executor, Codex Goal, Symphony, or autonomous browser test.

No additional path or effect is authorized by approval of this plan. A required additional implementation path, CLI behavior change, sibling write, or broader machine mutation is a plan revision and requires a new approval.

Canonical plugin catalog

Plugin version 0.2.0 contains exactly these twelve skill directories. Every directory contains SKILL.md and agents/openai.yaml.

Skill Selection Linear behavior Principal gate
linear-plan-change Explicit or clear ANU Product Main planning request Requires an existing Product Main parent Product-plan approval
anuva-plan-product-change Delegated Product Main planning or decision work Retains Product Main parent and children Phase-plan or decision approval
anuva-review-product-change Product completion request Completes the parent only after accepted children Product completion approval
linear-list-ready-issues Explicit read-only work discovery Reads eligible children only None
linear-implement-issue Explicit Implement ANU-<id> request Requires a valid child or explicitly requested standalone issue Exact implementation-plan approval
anuva-implement-issue Delegated validated issue implementation Uses the supplied issue only Exact implementation-plan approval
anuva-review-and-complete-pr Explicit issue completion request Completes the supplied child or tracked standalone issue One completion approval
anuva-repository-change Implicit or explicit current-repository request No issue by default; optional only on explicit request Material-plan gate when classified material, then merge gate
anuva-development-process-change Explicit only in Product Main Never creates an issue Material process-plan gate, then complete merge-set gate
anuva-preview-docs Docs change or explicit preview request None None for owned preview; strict verification at delivery gates
anuva-manage-development-environment Explicit environment operation None Install, removal, secret/tunnel administration, or destructive stop
anuva-manage-toolchain Explicit toolchain operation None Any confirmed install, upgrade, or removal

The Phase 1 anuva-development-readiness prototype is removed from the 0.2.0 source catalog. Its complete 0.1.0 installed cache remains intact as the Gate 2 rollback target.

Shared routing and approval contract

Work lanes

The plugin applies exactly these lanes before mutation:

Lane Required routing
Product change Product Main Linear parent and repository children where needed
Material single-repository implementation Issue-free by default, proportionate plan, separate plan approval, separate merge approval
Routine repository change Issue-free branch and draft PR; the request authorizes implementation, but not merge
Development-process change Explicit Product Main skill, no Linear, material plan approval, final merge-set approval
Machine/environment operation Read-only diagnosis by default; gate install, upgrade, removal, secrets, tunnel administration, or destructive stop

Authentication or authorization, privacy, security, billing, data or schema migration, deployment architecture, release coordination, shared application contracts, multiple implementation repositories, and uncertain ownership can never enter the routine, material-local, or development-process lanes.

Repository-local flow

anuva-repository-change first reads the active repository's AGENTS.md, ownership boundaries, likely affected paths, relevant Product Main contracts, and verification instructions.

It then returns one classification:

  • Routine: no Linear issue and no mandatory change folder. The user's request authorizes scoped implementation, affected tests, documentation verification, an intentional commit, push, and draft PR. Merge remains a separate gate.
  • Material: no Linear issue by default. Create a proportionate exact plan and stop. A subsequent approval authorizes implementation and draft PR delivery; merge remains a separate gate.
  • Product Main required: stop before branch or artifact creation and return an exact Product Main intake proposal.

When the user explicitly requests standalone Linear tracking, preserve the existing guarded anuva repository-change, linear-implement-issue, anuva-implement-issue, and anuva-review-and-complete-pr path. Optional tracking is a user choice, not an automatic consequence of a file change.

Issue-free branches use the repository codex/ prefix and a bounded descriptive slug. Git and GitHub remain the durable delivery plane. The skill may use scoped local Git and the connected GitHub capability, falling back to gh only where required. Named Anuva CLI operations remain mandatory for Linear state, fixed machine operations, documentation processes, and other implemented allowlisted side effects; Phase 4 adds no generic CLI command.

Plans and evidence

Do not create ImplementationPlan.md, ImplementationLog.md, and CompletionReport.md for every routine change. Require durable artifacts when they materially support a Product Main handoff, complex or high-risk work, long-running recovery, migration, cross-repository acceptance, or durable operational knowledge.

For routine work, the task record, PR description, tests, and updated behavior documentation may be sufficient. For material issue-free work, the plan may be the focused repository plan or another durable page appropriate to the scope; it must still be exact and separately approved.

Development-process flow

anuva-development-process-change is explicit-only and runs in Product Main. It:

  1. reads every affected repository but classifies exact process-only write paths;
  2. rejects product implementation and shared application-contract changes;
  3. creates one Product Main plan with repository impact;
  4. pauses for material-plan approval;
  5. creates one managed branch per approved repository;
  6. writes only approved plugin, CLI, policy, documentation, instruction, template, prompt, or tested-rule surfaces;
  7. validates each repository without hiding skipped expensive checks;
  8. creates one draft PR per repository;
  9. performs cross-repository acceptance;
  10. presents merge order and cleanup effects; and
  11. merges only after one explicit approval of the reviewed complete set.

It creates no Linear issue. Phase 4 tests this contract in read-only scenarios; Phase 5 is its first cross-repository migration use.

Environment and toolchain flows

anuva-manage-development-environment uses named anuva dev, documentation, and health operations. It may inspect or start a validated owned reversible process when requested. It must stop before machine tool installation or removal, secret changes, Cloudflare administration, or destructive process cleanup.

anuva-manage-toolchain uses:

anuva toolchain doctor --json
anuva toolchain snapshot --json
anuva toolchain bootstrap --dry-run
anuva toolchain bootstrap --confirm

Doctor, snapshot, and dry-run are read-only. A nonempty confirmed bootstrap is a separate exact machine-mutation gate. The skill accepts no arbitrary tool, package, URL, command, or path.

GitHub authentication

Every plugin skill that performs GitHub-backed delivery runs direct read-only gh auth status in the known keyring-capable approved context before the first GitHub-backed operation. It does not intentionally run a sandboxed failure first. Subsequent GitHub-backed Anuva or gh operations use that same context. It asks for authentication only when the keyring-capable check fails.

No token may enter repository files, plugin references, rules, logs, receipts, or machine configuration.

Bundled references

The plugin contains exactly:

  • references/DevelopmentProcessPolicy.md: a versioned, distributable policy reference derived from the durable Product Main policy;
  • references/RepositoryVerificationMatrix.md: repository ownership, AGENTS.md precedence, affected-scope rules, and the known verification emphases for Product Main, Bento, CMS, Python, and Unity; and
  • references/ToolchainPolicy.md: the packaged CLI, fixed-manifest toolchain, GitHub-authentication, preview, machine-mutation, and recovery boundaries.

The references must identify their Product Main source paths and policy version. Tests prevent the plugin's lane names, gates, and repository identities from drifting from the durable source. Repository AGENTS.md always wins for repository-specific product boundaries and checks. A conflict stops the skill; the plugin does not silently overwrite repository guidance.

Exact Product Main implementation scope

Plugin manifest and prototype replacement

  • plugins/anuva-development/.codex-plugin/plugin.json: set version 0.2.0, retain the skills-only manifest, and replace the readiness-only default prompt with the shared development-workflow prompt.
  • Remove:
  • plugins/anuva-development/skills/anuva-development-readiness/SKILL.md
  • plugins/anuva-development/skills/anuva-development-readiness/agents/openai.yaml

Skill source

Add SKILL.md and agents/openai.yaml under each exact directory:

  • plugins/anuva-development/skills/linear-plan-change/
  • plugins/anuva-development/skills/anuva-plan-product-change/
  • plugins/anuva-development/skills/anuva-review-product-change/
  • plugins/anuva-development/skills/linear-list-ready-issues/
  • plugins/anuva-development/skills/linear-implement-issue/
  • plugins/anuva-development/skills/anuva-implement-issue/
  • plugins/anuva-development/skills/anuva-review-and-complete-pr/
  • plugins/anuva-development/skills/anuva-repository-change/
  • plugins/anuva-development/skills/anuva-development-process-change/
  • plugins/anuva-development/skills/anuva-preview-docs/
  • plugins/anuva-development/skills/anuva-manage-development-environment/
  • plugins/anuva-development/skills/anuva-manage-toolchain/

The product and issue skills preserve their validated Linear contracts. The repository, development-process, environment, and toolchain skills implement the Phase 4 policy above. Shared implementation and review skills read AGENTS.md and contain no CMS-, Bento-, Python-, or Unity-specific command lists.

Plugin references

Add:

  • plugins/anuva-development/references/DevelopmentProcessPolicy.md
  • plugins/anuva-development/references/RepositoryVerificationMatrix.md
  • plugins/anuva-development/references/ToolchainPolicy.md

Tests

  • tests/unit/plugin-distribution.test.ts: require plugin version 0.2.0, the exact twelve-skill set, skills-only manifest, qualified installed naming, references, prototype removal, and retention of all eight Product Main compatibility skills.
  • tests/unit/skills-validation.test.ts: require source and cache validation for the twelve-skill plugin while retaining the existing compatibility contract and bounded cachebuster behavior.
  • tests/unit/plugin-skill-contracts.test.ts: add deterministic contract checks for lane names, escalation exclusions, approval boundaries, AGENTS.md precedence, issue-free defaults, optional Linear, GitHub-auth behavior, environment/toolchain gates, and absence of arbitrary execution.

Durable documentation

Update only:

  • docs/development/AnuvaDevelopmentPolicyPhase4ImplementationPlan.md
  • docs/development/AnuvaDevelopmentPolicyImplementationPlan.md
  • docs/development/DevelopmentProcessPolicy.md
  • docs/development/DevelopmentEnvironment.md
  • docs/development/ImplementationWorkflow.md
  • docs/development/ReviewAndCompletionWorkflow.md
  • docs/development/index.md
  • docs/engineering/AgentInstructions.md
  • docs/engineering/AnuvaCli.md
  • docs/engineering/CodexDevelopmentProcess.md
  • docs/engineering/LinearWorkflow.md
  • docs/engineering/PromptSkillCliModel.md
  • docs/engineering/Skills.md

These pages distinguish the installed Phase 4 plugin contract from the still-active checked-in compatibility path. They do not rewrite historical change records or claim that Phase 5 migration has happened.

Explicitly unchanged

  • .agents/plugins/marketplace.json: the local marketplace identity and source remain correct.
  • .agents/skills/anuva/**: retained byte-for-byte in Product Main.
  • AGENTS.md: active checked-in-skill routing remains the rollback contract until Phase 5.
  • src/**, config/**, scripts/**, package.json, and lockfiles.
  • Every path in Bento, CMS, Python, Unity, and anuva-dev-docs.
  • Codex user rules and Cloudflare configuration.

Implementation sequence

  1. After exact-plan approval, create codex/development-policy-phase-4 from current clean main; do not reuse the planning branch as implicit implementation approval.
  2. Use $plugin-creator for the existing plugin manifest/version update and $skill-creator for every new or redesigned skill.
  3. Capture the eight Product Main compatibility skill hashes and the implementation-repository skill inventory before editing.
  4. Replace the readiness-only source with the exact twelve-skill catalog and three references.
  5. Add contract tests, then update the listed durable documentation.
  6. Run focused plugin tests, packaged skill validation, the full Product Main check suite, documentation verification, and git diff --check.
  7. Confirm the diff contains only the exact Product Main paths and that all checked-in compatibility skill hashes are unchanged.
  8. Commit the complete Gate 1 source to the implementation branch.
  9. Present the exact committed plugin version, full commit, source tree hash, manifest hash, skill list, test evidence, current installed cache, intended marketplace refresh, expected cache transition, rollback procedure, and five-repository prompts. Stop for Gate 2 approval.
  10. After Gate 2 approval, perform only the approved local plugin upgrade, rollback, inverse rollback, and read-only fresh-task acceptance.
  11. Record Gate 2 evidence in this plan and the listed durable docs, rerun verification, commit, push, and create one focused draft PR.
  12. Review the exact PR head, complete diff, checks, reviews, comments, review threads, plugin state, and compatibility hashes. Stop for Gate 3 approval.
  13. After Gate 3 approval, ready and merge the exact reviewed head, synchronize main, and delete only the managed Phase 4 branch.
  14. Record merge completion in a focused status reconciliation before preparing Phase 5. Gate 3 does not authorize Phase 5 planning or implementation.

Verification matrix

Source and structure

  • bun test tests/unit/plugin-distribution.test.ts
  • bun test tests/unit/skills-validation.test.ts
  • bun test tests/unit/plugin-skill-contracts.test.ts
  • bun run check
  • anuva skills validate --json
  • git diff --check
  • exact plugin tree contains twelve skill directories and three references;
  • every SKILL.md has valid frontmatter and no placeholder;
  • every skill has valid agents/openai.yaml;
  • manifest has no apps, mcpServers, or hooks;
  • no temporary dependency installation or .validator-deps;
  • all eight Product Main compatibility skill hashes match the pre-edit values; and
  • every sibling repository remains clean and byte-identical.

Contract scenarios

Deterministic tests cover:

  1. CMS, Python, and Unity product behavior routes to Product Main Linear planning.
  2. Authentication or billing cannot enter a routine or development-process lane.
  3. A small CMS-local refactor is routine and issue-free.
  4. Material Python-local behavior requires a plan but no automatic Linear issue.
  5. A shared protocol change returns Product Main required.
  6. A plugin or AGENTS.md change requires explicit anuva-development-process-change and no Linear issue.
  7. Implement ANU-<id> preserves issue validation and the implementation-plan pause.
  8. Review and complete ANU-<id> uses one completion approval after a clean review.
  9. A failed check, review finding, conflict, or scope expansion stops before merge.
  10. Unrelated untracked files remain untouched unless they create a real safety conflict.
  11. Preview uses anuva docs preview before edits and one anuva docs verify per logical update.
  12. Toolchain and environment reads do not imply approval for a machine mutation.

Gate 2 live plugin acceptance

Before any installed-plugin mutation, present:

  • exact clean Phase 4 commit and branch;
  • source version 0.2.0;
  • plugin source tree and manifest SHA-256 values;
  • exact twelve skills and three references;
  • current 0.1.0 cache path and validation;
  • current marketplace source and enabled-plugin configuration;
  • expected new cache path;
  • whether a marketplace refresh alone is sufficient or the Codex plugin page must remove/reinstall only anuva-development@anuva;
  • confirmation that no CLI, PATH, toolchain, sibling file, or Cloudflare state changes;
  • the rollback branch switches and marketplace refreshes; and
  • the exact read-only fresh-task prompt matrix.

Upgrade:

  1. require a clean committed Phase 4 implementation branch;
  2. refresh the existing anuva marketplace registration from the Product Main root using the known Codex service_tier="fast" compatibility override;
  3. use a new Codex task to require the ...\anuva-development\0.2.0\ source locator and twelve plugin-qualified skills;
  4. if refresh alone does not select 0.2.0, stop and preview the exact remove/reinstall interaction before changing only anuva-development@anuva; and
  5. retain the 0.1.0 cache unless the Codex plugin page manages only one active cache.

Rollback:

  1. switch the clean repository to merged main, whose plugin source remains 0.1.0;
  2. refresh the same marketplace registration;
  3. remove and reinstall only anuva-development@anuva if required by the current Codex build;
  4. require a fresh task to report the 0.1.0 cache and readiness skill; and
  5. change no repository file or cache manually.

Inverse rollback:

  1. switch back to the exact clean Phase 4 implementation commit;
  2. refresh the same marketplace registration;
  3. remove and reinstall only the same plugin if required;
  4. require a fresh task to report 0.2.0 and all twelve skills; and
  5. finish with 0.2.0 active and the merged main 0.1.0 source retained as the durable rollback target.

Five-repository fresh-task matrix

Open a new Codex task rooted in each repository. Every task must:

  • report the exact 0.2.0 plugin cache locator;
  • list the expected plugin-qualified identities;
  • read the repository's AGENTS.md;
  • make no file, Git, Linear, toolchain, plugin, or Cloudflare mutation; and
  • run one natural-language classification-only prompt that names the installed Anuva development plugin plus one explicit $anuva-development:<skill> read-only invocation.

Expected scenarios:

Repository Natural-language classification Explicit read-only invocation
Product Main Shared plugin redesign selects the development-process lane, no Linear anuva-development:anuva-development-process-change scope audit
Bento Local deterministic test maintenance is routine and issue-free anuva-development:anuva-manage-toolchain doctor
CMS Local refactor is routine; auth/billing variant escalates anuva-development:anuva-repository-change classification only
Python Material local worker behavior requires a plan but no automatic Linear anuva-development:anuva-repository-change classification only
Unity Shared protocol change requires Product Main anuva-development:anuva-preview-docs health check

The CMS task must also discover its repository-local Mastra and text-to-speech skills. During coexistence, natural-language prompts explicitly name the installed plugin so results cannot be attributed to the older unqualified compatibility copy. Fully unqualified routing is a Phase 5 post-removal acceptance criterion.

Approval gates

Gate 1: source implementation

A separate approval of this exact plan authorizes:

  • the exact Product Main implementation paths;
  • creation of codex/development-policy-phase-4;
  • plugin source and test implementation;
  • documentation updates;
  • local source validation;
  • a clean Gate 1 commit; and
  • preparation of the exact Gate 2 preview.

It does not authorize marketplace refresh, plugin remove/reinstall, rollback, fresh-task live acceptance, sibling writes, checked-in skill removal, push, draft PR creation, readiness, or merge.

Gate 2: local plugin upgrade and acceptance

Only a separate approval of the concrete committed plugin identity, hashes, cache transition, exact plugin-page effects if needed, rollback, inverse rollback, and prompt matrix authorizes the live local plugin mutation and five-repository read-only acceptance.

Gate 2 authorizes recording its evidence, pushing the branch, and creating a focused draft PR. It does not authorize checked-in skill removal, sibling writes, PR readiness, or merge.

Gate 3: review and merge

Review the exact draft PR head, allowed paths, checks, reviews, comments, review threads, installed plugin identity, rollback evidence, fresh-task results, and compatibility hashes.

Ready and merge only on separate explicit approval guarded to the exact reviewed head. Gate 3 authorizes managed branch cleanup and local main synchronization. It does not authorize Phase 5.

Rollback

Source rollback is the Phase 4 PR revert. Because checked-in compatibility skills and all implementation repositories remain unchanged, reverting the plugin and documentation source restores the pre-Phase 4 repository contract.

Installed-plugin rollback uses the verified 0.1.0 marketplace source and cache procedure above. It does not delete caches or edit user configuration by hand. Inverse rollback must prove return to the exact accepted 0.2.0 source.

If plugin selection fails while checked-in copies remain, stop using the new plugin and continue only through the unchanged compatibility workflow. Do not remove compatibility copies to force discovery.

Stop conditions

Stop and request a revised plan or new approval if:

  • any path outside the exact Product Main implementation scope is required;
  • a shared application contract or product implementation change is found;
  • any sibling file or Git state would change;
  • any checked-in shared or repository-specific skill must be changed or removed;
  • an Anuva CLI or Codex rule change is required;
  • plugin version, source hash, cache path, marketplace source, or installed identity differs from the approved Gate 2 preview;
  • the 0.1.0 rollback target is missing or invalid;
  • a fresh task cannot distinguish the installed plugin from a checked-in copy;
  • a repository-local Mastra, text-to-speech, or other domain skill disappears;
  • source tests, plugin validation, strict docs verification, required PR checks, or review acceptance fails;
  • GitHub authentication fails in the known keyring-capable context;
  • plugin installation requires an unreviewed config edit or cache deletion;
  • tool installation, upgrade, removal, secret handling, or Cloudflare mutation becomes necessary; or
  • implementation differs materially from this plan.