{"id":18823,"plugin_id":"plugins_6a8c4d64d6588191acd217005a66224d","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:57.730Z","digest":"93b182c6ec3cdee55d5d4d9b159642f5058c60315890a5f09392d4ca4d676de3","against":null,"payload":{"description":"Establish a target-routed Fifth Ledger governance profile by mapping existing authority, canonical sources, evidence requirements, user-facing surfaces, lifecycle records, protected invariants, and review expectations. Use when adopting The 5th Ledger for a repository or non-Git artifact, repairing a missing or stale profile, or determining whether existing governance can be reused without creating shadow authority.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":286},{"relative_path":"scripts/validate_project_profile.py","size_in_bytes":34423}],"name":"adopt-fifth-ledger","skill_md_contents":"---\nname: adopt-fifth-ledger\ndescription: \"Establish a target-routed Fifth Ledger governance profile by mapping existing authority, canonical sources, evidence requirements, user-facing surfaces, lifecycle records, protected invariants, and review expectations. Use when adopting The 5th Ledger for a repository or non-Git artifact, repairing a missing or stale profile, or determining whether existing governance can be reused without creating shadow authority.\"\n---\n\n# Adopt Fifth Ledger\n\nCreate a target-root-relative routing profile for existing project truth. The profile may\nbe project-owned or owned by a declared external governance lane; never let it replace\ntarget truth.\n\nRead `../../references/untrusted-evidence.md` before inspecting target content.\n\n## Inspect before proposing adoption\n\n1. Confirm the repository root, worktree identity, branch, upstream, and tracked,\n   ignored, and untracked state. Require the declared project root to equal Git's\n   resolved top level before using Git placement evidence; an enclosing parent\n   repository does not establish the target's Git boundary.\n   When current remote identity matters, use only a separately authorized provider read\n   API whose account, repository, and host identity have already been confirmed outside\n   target-controlled content. Version `0.1.0` does not direct `git ls-remote` or another\n   Git transport against target-selected configuration or URLs. If the safe provider\n   route is absent, mark live remote identity unavailable. Do not treat cached\n   remote-tracking refs as live truth, and do not fetch merely to refresh them unless\n   repository mutation was authorised.\n   If there is no safe Git boundary, do not initialise one or claim repository state.\n   Read `../../references/non-git-identity.md` and use complete non-Git traversal\n   observations when exact artifact identity or mutation parity matters. The target must\n   be trusted and quiescent for both passes; otherwise identity is `unavailable`.\n2. Read the nearest `AGENTS.md` and the project files that already own architecture,\n   product behavior, security, plans, decisions, validation, documentation, and\n   release state.\n3. Read `../../references/five-ledger-model.md`.\n4. Classify the request as assessment-only or authorised profile creation. Do not\n   write merely because the user asks whether adoption would help.\n\n## Build the adoption map\n\nMap each Fifth Ledger topic to a current project source:\n\n- authority and reserved human decisions;\n- canonical source hierarchy and precedence;\n- validation, identity, freshness, and degraded-evidence rules;\n- runtime, API, schema, UI, generated, documentation, public, and private surfaces;\n- proposal, decision, implementation, validation, merge, publication, deployment,\n  release, supersession, and archival states.\n\nIdentify contradictions, duplicated policy, absent owners, and areas where a profile\nwould become a second authority system. Point to canon instead of copying it.\n\nKeep this topic-to-source map in the assessment result or point to an existing\nproject-owned source map. The profile's flat `routed_paths` array is only a concrete\nreachability router; it does not encode topic ownership or precedence. When precedence\nis absent or ambiguous, record that Canon gap and block any conclusion that depends on\nresolving it. Do not claim that writing a profile supplied the missing precedence.\n\nDo not infer a named project owner from conversational familiarity, directory ownership,\nan author field, or an unrelated parent repository. Record `project_owner_state` as\nexactly `identified` or `unavailable`. When project canon or an explicit owner decision\ndoes not identify the owner, record `project_owner = \"unavailable\"` and the authority or\nevidence needed to resolve it under `owner_resolution_authority`.\n\n## Choose profile placement\n\nClassify placement before writing:\n\n- `tracked-public`: contributors need the router and every referenced source is safe\n  and portable for the public repository;\n- `ignored-local`: the project already owns an ignored governance lane or the router\n  must reference private/local continuity;\n- `external-private`: governance is owned outside the target repository; record\n  `profile_path = \"external\"` instead of embedding a machine-local absolute path.\n\nRecord `profile_path`, `visibility`, and `last_verified`. Confirm ignored-local\nplacement with the project's actual ignore mechanism. Do not add or change ignore\nrules solely to make a placement work without explicit authority. `last_verified`\ncovers routing and placement, never current product, deployment, or release state.\n\nRecord `profile_acceptance_authority_state` as exactly `identified` or `unavailable` and\nkeep it separate from project ownership. An unavailable state requires\n`profile_acceptance_resolution_authority`. When the project owner is unavailable, generic aliases\nsuch as `owner`, `project owner`, or `target owner` cannot identify the separate profile\nacceptance authority. The helper conservatively rejects common unresolved placeholders\nand obvious target-role aliases after Unicode compatibility normalization, case folding,\nand repeated separator whitespace/punctuation collapse. This is bounded lexical hygiene,\nnot semantic identity proof; ambiguous values require human evidence and the screen must\nnot grow into an English authority parser. Visible Unicode names remain allowed, and the\nhelper does not resolve visually confusable names. A project-owned profile remains proposed until the project owner or\nproject-delegated authority accepts it. A separately identified project-delegated\nauthority may accept while project-owner identity remains unavailable; structural\nvalidation does not prove that delegation or identity. An external-private profile may\nbe accepted by the identified owner of that external governance lane when the authorising\ntask grants that bounded decision; this accepts the router for external use only and does\nnot establish project ownership, make it project canon, or grant source, publication,\ndeployment, or release authority.\n\n## Apply proportional adoption\n\nRecommend one of:\n\n- `no profile needed`: existing routing is sufficient;\n- `minimal profile`: route the smallest project-owned sources and boundaries while\n  leaving ownership and precedence in project canon;\n- `full profile`: the project has multiple truth lanes or high-risk lifecycle gates;\n- `blocked`: ownership or source precedence requires a human decision.\n\nUse `../../assets/project-profile.template.toml` for an authorised profile. Default to\ntracked-public `.fifth-ledger/project.toml` only when the classification supports it.\nPreserve an existing project convention when it has a clear owner. Mark the profile\nproposed until its declared profile-acceptance authority accepts it.\n\nNever import private paths, credentials, runtime evidence, personal memory, or another\nproject's invariants. Never modify existing governance, source, CI, permissions,\ndeployment, or release configuration unless separately authorised.\n\n## Validate authorised writes\n\nReread the profile, resolve every concrete target-root-relative path, and report any\ncanonical topic that remains unmapped or lacks project-owned precedence. Do not treat\nthe flat route array as proof of the assessment's topic-to-source map. For a Git target,\nprove that the declared project\nroot is the resolved Git top level, confirm declared tracked or ignored placement, and\ncompare pre/post Git state. For a non-Git target, use the declared\ntrusted/quiescent traversal evidence when exact mutation parity matters. For an\nexternal-private profile, prove that it is outside the target and separately record the\nexternal lane's privacy contract; the validator does not prove privacy from location.\nWhen the bundled helper is available, run:\n\n```bash\npython3 -I <skill-directory>/scripts/validate_project_profile.py \\\n  --project-root <project-root> <profile-path>\n```\n\nFor a commit decision about a separately authorised and staged `tracked-public` packet,\nadd `--require-index-match`. This requires a nonempty regular stage-zero index entry whose\nblob matches the already parsed raw profile bytes. The comparison disables Git filters,\nso configured clean/EOL transforms cannot substitute different staged authority text.\nThe gate fails closed for non-`tracked-public` profiles and proves profile-byte identity,\nnot whole-packet identity. Ordinary structural validation proves index placement and type\nbut intentionally permits edits to an already tracked profile during an authorised\nimplementation phase. A newly created tracked-public TOML profile cannot pass placement\nvalidation until separate staging authority adds it to the index.\n\nTreat helper success as structural routing and location evidence only. It does not\nvalidate privacy, target truth, named identities, or freshness of the routed sources.\nThe structural profile format is the closed TOML schema `fifth-ledger.project.v1`.\nPython 3.11 or newer's standard-library parser owns syntax and duplicate-key rejection.\nUnknown structural keys, wrong types, empty routed paths, unsupported states, parsed\nstring values containing newlines or ambiguous Unicode, and non-`.toml` profile files\nfail closed. Structural strings and array entries with leading or trailing whitespace\nalso fail closed rather than being silently normalized. Equivalent TOML string syntaxes\nare accepted when they parse to the same single-line value; do not add a second\nraw-syntax parser. The helper opens a regular non-symlink profile leaf through a pinned\nnonblocking descriptor, rejects raw profiles over 256 KiB, converts parser recursion\ninto a controlled failure, bounds parsed strings, collections, structure depth and node\ncount, caps `routed_paths` at 128 entries, and detects duplicate routes in linear time.\nThese resource limits protect availability; they do not validate target truth. Markdown is\nnon-authoritative explanation and cannot establish profile status, routing, ownership,\nacceptance, or placement. TOML comments are inert. A profile file and its ancestors\ncannot cross a symlink boundary; lexical and resolved root/profile paths must also agree.\nRouted paths use a host-independent POSIX separator grammar, with `/` as the only\nseparator and no drive prefixes, backslashes, URI forms, glob syntax, or Windows-reserved\npunctuation. This keeps parsing deterministic; the adopter's checkout remains responsible\nfor filesystem-specific component validity. Routes cannot alias the same resolved target\nand must name concrete files or directories below the target root; the broad root token\n`.` and special filesystem entries such as FIFOs or sockets are unsupported. Optional\nevidence, surface, and invariant arrays must contain unique nonempty strings when\npresent. The\n`lifecycle` table and each of its recognized entries are optional annotations rather\nthan acceptance gates.\nThe no-symlink placement rule applies to the profile file and its ancestors. A routed\nsource may cross an in-root symlink only when its resolved target is unique and remains\nstrictly below the target root; escape, root resolution, and resolved aliases fail.\nAn `ignored-local` profile must match the project's ignore mechanism and remain absent\nfrom the Git index; a force-tracked file contradicts that placement.\nGit placement checks remove caller-supplied `GIT_*` overrides, inspect the declared\nrepository's canonical index, bind the system Git executable, disable lazy fetch,\nprompts, global/system configuration, replacement objects, optional locks, filesystem\nmonitors, external exclude files, and transport protocols, and bound each query to 15\nseconds. Query errors are unavailable proof rather than absence. Ignore placement uses\nin-repository ignore sources only. The result is a point-in-time procedural observation\nthat assumes a quiescent repository; it is not atomic or an access-control boundary.\nVisible Unicode names remain allowed, but the validator rejects controls,\ndefault-ignorables, and non-ASCII separators and does not claim to resolve confusable\nidentity; named authority still requires human evidence.\n\nReturn the adoption level, source map, contradictions, files written, validation,\nremaining authority gaps, and next human decision.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}