agentic-praxis-grimoire

APG8 RepoMap Managed Projection Adoption

Objective and result

APG8 accepted the APG7A correction and performed the first authorized real-project mutation through apg-project-skills. The command adopted RepoMap’s six existing compatible manual APG links into managed project-local state and verified them without changing RepoMap’s tracked repository.

Terminal result: managed-adoption-complete.

This is deployment evidence for one opted-in project. It does not establish automatic invocation, comparative improvement, stable maturity, production readiness, publication readiness, or Superpowers decommission readiness.

Authority boundary

RepoMap was authorized only as a target for the local projection state owned by adopt and check: the existing project skill links, the Git-local ownership state, and the exact managed exclusion block. RepoMap’s tracked tree, index, branch, commits, remotes, configuration, runtime, graph state, database state, and report destinations remained outside the write scope.

The maintainer synchronized the target before adoption. Because RepoMap also had active development elsewhere, later upstream advancement was explicitly classified as non-blocking; APG8 preserved the synchronized target branch and did not fetch, merge, pull, reset, commit, or push it during adoption.

Accepted APG7A basis

APG7A is externally accepted as Complete — idempotent install and adopt compliance corrected. APG8 used the corrected command unchanged. The shared semantic-status guard, 28-family suite, state version, exclusion grammar, ownership model, locking, transaction ordering, and rollback design were not reopened.

Before state

Preflight established:

• six existing symbolic links with exactly the canonical APG skill names;
• every raw and resolved link target matched the current canonical leaf;
• every linked SKILL.md was readable, byte-identical to its canonical file, and declared the matching frontmatter name;
• the links and their parent directories were untracked and ordinary;
• no seventh APG projection existed;
• no APG ownership state or managed exclusion block existed;
• six pre-existing exact manual exclusion entries remained user-owned;
• normal Git status, the tracked worktree, and the index were clean; and
• no projection mutation lock or Git operation was active.

The corrected 28-family projection suite, executable help, Python byte compilation, canonical skill validation, and APG’s checked-in projection validation passed before target mutation.

Unmanaged pre-check

An explicit read-only check named all six skills. It returned operational exit 1 and reported that the requested skills were not locally managed. This was the expected disposition: compatible manual links do not grant tool ownership.

The result was not worked around. Adoption proceeded only after independent before-state evidence established exact compatibility.

Adoption result

The default all-six command was used without per-skill selection:

apg-project-skills adopt --repo <repomap-root>

It returned exit 0, reported six managed skills, and emitted the full Codex application restart reminder. It did not create, replace, retarget, copy, or remove any link.

Managed checks

Both supported forms passed:

• default check: six managed skills verified;
• explicit six-name check: six managed skills verified.

The resulting private version-1 state has the exact accepted keys, current canonical and target roots, six sorted unique managed names, and no created containers. Its permissions are private. One exact APG exclusion block agrees with state.

Preservation evidence

Before-and-after comparison proved:

• all six link inodes were unchanged;
• all raw and resolved link targets were unchanged;
• all canonical and linked skill hashes were unchanged;
• all six pre-existing manual exclusion entries remained outside the managed block and byte-identical;
• no separator repair was needed;
• normal Git status remained clean;
• the branch, commit, tracked tree, index, and Git configuration were unchanged;
• no tracked or staged diff existed;
• no unexpected local APG metadata path appeared;
• no RepoMap commit, push, or managed report was created; and
• user-level Codex and Superpowers sentinels were unchanged.

Pre-existing exclusion content remains user-owned. APG8 did not delete, consolidate, reorder, normalize, or claim those entries.

APG skill decisions

• planning-repository-work applied because the accepted deployment required dependent preflight, before-state, mutation, verification, evidence, review, and closeout units with a strict stop boundary.
• reviewing-and-verifying-repository-work applied to claim-specific target verification, complete-diff review, and terminal acceptance.
• composing-bounded-worker-assignments applied only to the separately authorized fresh read-only reviewer assignment.
• designing-significant-changes was a material non-trigger because ADR 0004 already owns canonical source, local state, adoption, conflict, and rollback.
• implementing-with-test-discipline was a material non-trigger because the accepted command passed; APG8 changed no executable behavior or test.
• debugging-systematically was a material non-trigger because the initial synchronization issue was explained by ordinary upstream advancement and the adoption itself produced no unexplained failure.

No Superpowers skill was invoked or followed.

Rollout and decommission effect

APG8 adds real-project evidence for managed adoption and check while preserving manual link identity and a clean tracked repository. Together with earlier evidence, the following gate components are supported:

• material Superpowers workflow mapping;
• real APG use;
• real use in an additional project;
• preserved Superpowers source and provenance;
• tested project-local install, adopt, check, and uninstall behavior;
• real-project managed adoption and check; and
• a documented human decommission and rollback runbook.

The full gate remains incomplete. Broader repeated workflow use across active projects, a reviewed dependency inventory, an explicit human decommission decision, actual global disable or removal, and post-decommission smoke and rollback evidence remain unresolved.

All six skills remain provisional. Superpowers remains globally installed, unchanged, and reference-only for APG. Decommission readiness remains false.

Privacy and limitations

Public evidence uses only the canonical identity repo-map and generalized local-state categories. Exact checkout identities, private paths, commits, link targets, inodes, hashes, state contents, exclusion bytes, and reviewer snapshots remain publication excluded.

The evidence covers one synchronized macOS worktree and one all-six adoption. It does not test partial real-project adoption, uninstall, hostile concurrent writers, abrupt process loss, another operating system, or Codex discovery after restart. No real-project rollback was needed or authorized.

Next fresh-session boundary

The next gate is a full Codex application restart followed by a fresh RepoMap session that verifies project-skill discovery and records actual invocation only when observable. APG8 does not perform that restart or begin the smoke automatically.

This site is open source. Improve this page.