agentic-praxis-grimoire

v0.3 Guidance Migration Proposal

Purpose and authority

This APG22 proposal classifies public, project, and private guidance owners and defines shadow, cutover, and rollback gates. It authorizes no root rewrite, private-skill decommission, target-repository change, public release, or active- integration mutation.

Ownership model

Guidance class	Proposed owner
Human authority, instruction precedence, privacy, destructive-action, and universal repository stops	Applicable root instructions and current task
APG process selection	Public workflow router
Mixed-corpus ownership, rights, privacy, and migration disposition	Guidance-synthesis leaf
Reusable language, test-harness, and engine judgment	Matching retained profile
Exact versions, commands, thresholds, layouts, schemas, coverage, deployment, and runtime policy	Target repository
Capability adoption, correction, maturity, deprecation, and removal	APG authoring lifecycle
Technically valid skill-file construction after semantic acceptance	Native Codex skill authoring
Public distribution and active integration	APG release owners under human authority
Personal, machine, private-repository, installed-tool, and host-integration guidance	Private overlay

The model is synthesis-first. A source file or private skill is evidence, not a one-to-one public migration unit.

APG root proposal

No reduction is justified. Retain the current classes:

• human and phase authority, precedence, and scope;
• designated-source read-only treatment;
• retired external-workflow prohibition;
• provenance, public/private, validation, and completion triggers; and
• the concise project map.

Detailed procedures already live in linked owners. No shadow or cutover phase is required unless a later real duplication is introduced. A future change must preserve repository authority, validate links and non-triggers, and restore the exact prior root on rollback. APG root shrinkage is not a v0.3 release dependency.

RepoMap root proposal

A separately authorized RepoMap phase may reduce duplicated detail while preserving a concise authoritative root.

Retain in root:

• repository identity, precedence, task scope, compatibility, and non- expansion rules;
• static non-execution, privacy, redaction, destructive-action, and runtime stops; and
• concise routes to contributor and APG owners.

Route after their prerequisites pass:

• phase and testing procedure to RepoMap contributor owners;
• generic process selection to the APG router and process leaves; and
• generic Python, Go, and PostgreSQL judgment to matching profiles.

Keep project-local:

• exact commands, toolchains, paths, graph semantics, schema and migrations;
• compatibility promises, thresholds, final gates, container/runtime policy; and
• active refactor authorization and temporary roadmap state.

Keep private:

• credentials, secrets, and protected payloads;
• private topology, runtime identities, and raw operational evidence; and
• personal or machine-specific configuration and values.

Required sequence:

1. Refresh the target from its current accepted source; APG22’s inspected snapshot was behind its remote baseline.
2. Inventory exact units and accept the target-owned design.
3. Publish v0.3 and install the applicable managed projection.
4. Shadow old root guidance and proposed routes while the root remains authoritative.
5. Obtain discovery, explicit-use, non-trigger, no-skill, overlap, false- escalation, and project-override evidence.
6. Independently review route parity and byte-restorable rollback.
7. Cut over only under RepoMap maintainer authority.
8. Remove stale routes only after post-cutover validation.

Rollback restores the exact prior root and prior managed projection. The RepoMap migration is optional and does not block APG v0.3.

Private guidance and router proposal

Keep personal style, machine topology, host escalation, private graph/runtime, unsupported-language, exact dependency, and local integration guidance private. Generic process or retained-profile judgment may shadow public APG only after public v0.3 and active integration are available.

The private same-name APG router is replaceable by the current public owner but requires public v0.3 distribution and active-integration cutover first. It is materially older: it advertises only six process leaves and lacks current domain-profile, checked-map, duplicate-source, and integration-fault behavior.

Transition gate:

1. Preserve the private router and current active source as restoration input.
2. Publish and validate v0.3 under APG24 authority.
3. Update active integration through the accepted public-source lifecycle.
4. Shadow both same-name sources without inferring precedence.
5. Obtain source-qualified fresh-session discovery and exercise explicit use, no-skill, non-trigger, overlap, domain pairing, stale metadata, project override, and rollback while both sources remain restorable.
6. Decommission only in a separately authorized private migration phase after the shadow evidence passes.
7. Repeat source-qualified discovery after cutover and restore immediately on regression.

APG24A records the subsequent terminal disposition for the personal router. The maintainer-reported source-qualified fresh-session shadow passed, and the personal same-name router was then decommissioned under separate human authority. Focused verification finds the public-backed aggregate active with all nineteen skills, the former personal router absent, the other personal skills preserved, and an exact tracked private restoration source. This closes that router transition only; it does not approve another private-skill decommission or a broader root cutover.

Other bounded private dispositions:

Private capability class	Disposition
Docs-only hygiene	Not justified for public migration
General project-test strategy	Partially replaceable through synthesis; exact defaults remain private/project-owned
RepoMap phase workflow	Partially replaceable; correct target-specific stale wording before decommission
Nix repository workflow	Project-specific and machine/personal; retained
Git-history workflow	Generic part partially replaceable; personal-flow portion retained
Host escalation	Machine/personal and retained; not justified for public migration

Native authoring and manager assignments

No separate public writing skill is justified. Guidance synthesis classifies a mixed corpus; APG lifecycle decides capability adoption and evidence; native Codex authoring constructs a valid skill after those decisions.

The historic manager-assignment corpus supports a distinct future candidate for converting one already human-approved roadmap phase into one reviewable top-level Codex manager assignment. It cannot approve or extend a roadmap, grant delegation or mutation authority, dispatch work, or replace planning, worker-assignment composition, routing, or the manager-worker protocol. A separately authorized evaluation must compare ordinary prompting across public- safe contexts before optional implementation.

Release dependency

This proposal itself closes the APG22 migration-design objective. No root cutover or private decommission is required before APG23. Public-router migration and active integration remain APG24 and post-distribution work.

This site is open source. Improve this page.