diff --git a/docs/architecture/PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION.md b/docs/architecture/PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION.md new file mode 100644 index 0000000..02eb162 --- /dev/null +++ b/docs/architecture/PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION.md @@ -0,0 +1,275 @@ +# Project Hygiene and Repository Reconciliation + +## Decision, maturity and owning boundaries + +Increment: `PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION_V1`. +Native target capability: `FORGE::PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION_V1`. +This is a documentation/roadmap decision: `PENDING_PR` until each owning merge, +then canonical target architecture. It does not implement a scanner, API, +maintenance executor, table, schedule or UI, and activates no cleanup permission. + +This capability extends [Project Intelligence](PROJECT_INTELLIGENCE_AND_DYNAMIC_PLANNING.md), +not the Mission execution engine. It uses [effective policy](POLICY_GOVERNANCE_AND_EFFECTIVE_PROFILES.md) +and [governed progression](GOVERNED_PROGRESSION_AND_DELIVERY_AUTHORITY.md). +The [scoped roadmap](../roadmap/PROJECT_HYGIENE_V1.md) and +[documentary DAG](../roadmap/project-hygiene-v1.json) do not replace the +executable bootstrap programme or alter live grants. + +| Responsibility | Authority | +| --- | --- | +| Actual remote refs, PRs, reviews and protected-ref settings | The declared repository provider/project authority | +| Host checkout/worktree facts, leases, run provenance, mutation and cleanup receipts | EP and its qualified host/provider boundary | +| Project-wide observations, anomaly classification, semantic reconciliation, residual routing and proposals | Forge | +| Human chat, Repository Health, evidence presentation and governed decisions | Workspace; actual decision authority remains with the declared owner | +| Installed artifact composition, update/uninstall/rollback and installation state | Forge Platform and product-owned installation contracts | + +Forge may consume authorized read-only provider facts through declared adapters; +local host inspection and all target-repository/ref/worktree mutation remain +EP-owned. Forge still writes its own cases and projections in Forge-owned central +runtime storage; that is not permission to mutate a target repository. Neither +Forge nor Workspace reads EP CENTRAL, walks another product's data-root or uses +an LLM shell as a substitute adapter. Project identity comes from the canonical +repository declaration, never a branch prefix or incidental checkout path. + +## Three kinds of work; no Mission for every maintenance question + +**Run finalization cleanup** is an EP lifecycle responsibility. For its own +proven-delivered resources, EP reconciles delivery and conditionally cleans only +its owned branch/worktree while retaining the valid coordination lease until +safe finalization. No Forge Mission, project-wide scan or semantic model is needed. +A cleanup warning must not overwrite proven delivery or fabricate a failed run. + +**Project hygiene** is a bounded Forge application operation/case. Requests such +as “what remains on this old branch?” or “inspect stale branches” resolve to +read-only observation and, only where useful, a reconciliation case. The case is +not a Mission Candidate, Mission, Engineering Action or EP execution run. It +has its own correlation, policy, evidence and finite analysis budget in existing +Forge-owned storage. An existing Action/run can be a provenance reference, not a +mandatory parent or an identity manufactured for the case. + +**Genuine residual product work** is not executed by the hygiene case. Forge +may propose a successor under a still-applicable approved Mission, or a Mission +Candidate/amendment/other already-governed engineering intake when no such scope +exists. A completed Mission is not silently reopened. New architecture, security +or write scope follows its real gate. No direct cherry-pick, hidden maintenance +Mission or generic “hygiene” shell route bypasses normal product qualification. +Accepted salvage is a new bounded change against current main, never wholesale +replay of an old branch merely to make the ancestry graph look merged. + +```text +EP run result / provider event / bounded schedule / Workspace request + -> scoped observation -> Forge Project Context + provenance projection + -> no anomaly: done + -> ambiguous: RepositoryReconciliationCase + -> retain / already delivered / accepted supersession + -> genuine residual: governed engineering proposal + -> permitted cleanup proposal: EP admission + current safety checks + -> EP receipt/readback -> Forge case reconciliation -> Workspace projection +``` + +A cleanup request is a separate bounded EP maintenance command using existing +admission/provider/lease/evidence services, not a new execution mode or queue. +A Mission ID is optional provenance for this operation, not a required fiction. +Until that command seam is implemented and qualified, Forge can recommend or +retain, but cannot substitute an arbitrary Engineering Action or shell command. + +## Observation schedule and completeness + +After a terminal EA result (including failed/blocked results), delivery or +cleanup receipt, Forge requests a cheap **delta** refresh of the affected +repository and known branch/worktree identities. External Codex/developer PRs +and provider events are also inputs; they need not originate in Forge. Use +bounded periodic full inventory to recover missed events, plus on-demand and +release/canary preflight refreshes. Exact intervals are policy/configuration, +not hardcoded cron or a full model call after every Action. + +Persist cursors, source event IDs and coalesced refresh jobs in the existing +Forge runtime. Duplicate/out-of-order events are deduplicated and reconciled +against provider revision/evidence, not local wall-clock ordering alone. An +unknown event gap, permission-limited page, offline Agent, shallow history or +rate-limited response makes the relevant snapshot `PARTIAL`/`STALE`/`UNAVAILABLE`. +It never means “zero branches” or “no active work”. A full rescan repairs a gap; +an event itself grants no mutation authority. Do not extend a run's lease or +hold its completion open merely to await project-wide analysis. + +Every snapshot records project/repository/provider identity, observation ID, +source revisions/cursors, observed ref-to-object mapping, relevant main/base +revision, PR/delivery references, host/worktree coverage, freshness and limits. +Bound API calls, bytes/diff size, analysis time/tokens/cost, concurrent cases, +retention and retries. Pause/cancel and exhausted budgets retain evidence and +produce a resumable case or recommendation, not a new case to reset allowance. +Read-only observation uses least-privilege access; no untrusted repository hooks, +builds or tests execute as a side effect of scanning. Qualified tests, if needed +for reconciliation, run through EP under a separately authorized bounded request. + +## Branch Provenance Ledger is a projection, not another Git authority + +Use a logical ledger within existing Forge Project Context/storage. It indexes +facts and their sources; it does not replace Git, PR history, EP leases or +execution receipts. Rebuildable views and immutable analysis/decision records +are distinguished. No second database service is introduced. + +A branch record binds repository ID, provider/remote identity, full ref, observed +object ID, ref-generation/provider event revision where available, base/main +snapshot, nullable creation provenance, known Action/run/increment/PR links, +delivery evidence, worktree observations, retention/legal hold, case references, +last observation and explicit coverage/freshness. Host paths are scoped operational +references, not portable domain identities. Names reused for another branch +instance invalidate previous proposals; unknown generation/provenance remains +unknown. A branch name, author string, ahead/behind count or age is not ownership. + +Do not compress all meanings into one mutable “safe” flag. Keep separate axes: + +- activity: active Action/PR/lease, no known activity, unknown coverage; +- delivery: merged/reconciled, superseded candidate, residual, conflicting evidence; +- case: open/investigating/waiting/concluded, with immutable conclusion revisions; +- cleanup: not requested, retained, proposal, eligible-at-observation, admitted, + partial/completed/denied/stale, with EP receipt references. + +`SAFE_DELETE` may be shown only as a qualified shorthand for a scoped policy +eligibility observation. It is not an enduring permission or a delete receipt. +A `SUPERSEDED_RECONCILED` case can legitimately end with `RETAINED` cleanup. +Remote branch deletion says nothing about a local branch or worktree deletion. + +## Reconciliation and strength of evidence + +Start deterministically: exact delivery receipt/head, PR merge facts, ancestry, +changed-path and tree comparisons, then patch equivalence as a diagnostic aid. +Git reachability and content/intent equivalence are different questions. Squash +or cherry-pick can preserve work without preserving the original commit IDs; +even a merged PR does not cover commits later appended to its head branch. + +Escalate to bounded semantic analysis only for unresolved cases. Bind it to the +exact source head, comparison main, commit range, relevant contracts and test +identities/results, analyzer/model/tool revision and analysis policy. Repository +content, commit messages and PR comments are untrusted evidence, not instructions +or grants. Preserve FACT / INFERENCE / RECOMMENDATION / DECISION distinctions. +Do not export proprietary source to an unapproved model/provider. + +For each commit intent or independently meaningful residual, record: +`PRESENT_ON_MAIN`, `SUPERSEDED_BY_STRONGER_MAIN_IMPLEMENTATION`, +`GENUINE_RESIDUAL` or `UNRESOLVED`, with exact code/test/evidence references, +uncertainty, contradictory evidence and reviewer/decision provenance where +required. “Stronger” requires a compatibility/behavior explanation; a newer +version number, similarly named test, green unrelated suite or model confidence +is not proof. Testing observed behavior does not prove universal equivalence. + +All mapped intents can support a proposed no-residual conclusion. Semantic +analysis alone never authorizes destructive cleanup. For semantically superseded +history, the target requires an accepted bounded disposition under the effective +policy and a verified retained recovery object/bundle before destructive cleanup. +No automatic semantic-delete path is enabled by this document. An unresolved or +residual case remains retained and may become governed product work. + +## Safe cleanup is a separate operation + +EP owns the actual decision at the side-effect boundary. Its +[owning contract](https://github.com/pcvantol/engineering-platform/blob/main/docs/engineering/REPOSITORY_HYGIENE_AND_SAFE_CLEANUP.md) +requires all applicable gates together: authenticated scoped actor/delegation, +permitted operation, current expected ref/worktree state, verified ownership or +explicit approved adoption, no conflicting active owner/PR/run/lease, protected-ref +policy, retention checks, current repository facts and retained recovery evidence +where required. Analysis authority, scan permission and provider push access are +not delete authority. The finalizer's own valid coordination lease is not a +conflicting owner; retain it during cleanup of its proven-delivered resources. +A separate maintenance command cannot borrow another run's finalizer authority. + +Separate local ref deletion, remote ref deletion and owned worktree removal. +A request freezes the exact set and expected object IDs plus proposal/evidence/ +policy revisions. No recursive path, wildcard branch, age-only or prefix-only +cleanup. Main/default/release/protected refs, tags, unknown ownership, active +work, dirty/untracked/ignored user files and runtime directories are retained. +Git-clean does not mean a worktree contains no valuable ignored data. + +Immediately recheck state under EP's resource exclusion and use a provider's +atomic expected-ref mutation where available. An EP lease does not lock out +external Git users. If the provider cannot enforce the needed conditional +mutation, unattended cleanup is unsupported: retain or use a separately +qualified controlled operation, not check-then-blind-delete. + +No distributed transaction is claimed for remote ref, local ref and worktree. +Persist operation intent before effects and individual outcome receipts after +each stage; timeout/lost acknowledgement reconciles the same operation. Partial +cleanup is visible. Never recreate a branch as “rollback” if doing so would +clobber somebody else's new ref. “Already absent” is an observation, not invented +proof that this operation deleted it. Recovery bundles/archives must be protected, +verifiable and governed by retention; creating an archive is not permission to +publish source or create release-triggering refs. + +## Policy and Workspace interaction + +Reuse the product-owned policy definition/assignment/effective-evaluation +contracts and their qualified services as available; this design does not claim +that the full policy management implementation already exists. A project profile +controls observation triggers, analysis escalation/budgets, protected/retained +refs, evidence freshness, adoption and retention rules, and which bounded cleanup +classes may use existing delegation. Mandatory controls combine; allowed scopes +intersect; budgets use remaining ceilings. A Mission assignment can narrow +relevant scope, not grant deletion of unrelated branches. Risk/semantic ambiguity +may require a gate; deterministic own-run cleanup within an existing grant must +not demand a new human click every time. + +Workspace chat and Repository Health share the same typed request/decision +boundary. “Explain this branch” is read-only. “Reconcile it” permits analysis, +not deletion. “Clean everything safe” resolves an explicit project-scoped set +and policy proposal; new branches are not added after confirmation. The owner +service binds any decision to that set, its revisions, actual actor and expiry. +A chat transcript, LLM response or UI selection is not approval by itself. + +The [Workspace design](https://github.com/pcvantol/workspace/blob/main/docs/REPOSITORY_HEALTH_AND_RECONCILIATION.md) +shows evidence, exclusions, uncertainty, external gate owners and per-target +outcomes. It cannot hold provider-admin credentials, invent Missions or use a +local client filesystem as authoritative evidence for unseen hosts. Routine +delegated work may run without UI; unsupported operations remain read-only. + +## Release, canary and installation boundaries + +A release/canary hygiene assessment binds the selected repository, exact source, +artifact operation and execution scope. Relevant conflicting owners, unexplained +changes to that candidate or missing required evidence can block that operation. +An unrelated retained branch or an unavailable optional scan does not create a +global release ban. Coverage must be explicit: one closed case does not prove +`UNEXPLAINED_REPOSITORY_BRANCHES = 0` for the whole project. + +The full scanner, semantic reconciliation and Workspace surface are **not new +prerequisites** to the first serial autonomy canary. A small read-only hygiene +slice may be selected as canary product work without implying the whole family +is implemented. Existing minimum EP preflight/lease/cleanup safety still applies. + +Forge Platform consumes an applicable assessment as source/operation evidence; +artifact digests, supply-chain qualification, publication, install readiness and +external CD approvals remain separate gates. Installing, upgrading or uninstalling +a product must not prune project refs, erase Forge cases/EP receipts or reset +budgets. See its [owning boundary](https://github.com/pcvantol/forge-platform/blob/main/docs/architecture/REPOSITORY_HYGIENE_RELEASE_BOUNDARY.md). + +## Reference case and qualification targets + +The user-supplied `codex/ep-producer-completion` case is a historical example: +head `c68ab079825aa58370b341f3b5087c147b7633ff`, compared with EP main +`f7c08872a2d334cff097ea5f28822836e59f78c3`, six ancestry-unique commits, zero +reported residuals, local/remote branch removed and `.engineering` retained. +Its manual reconciliation is not native scanner/executor qualification, not a +current inventory, and not new permission to delete anything. + +Required future tests include: exact merge versus squash-equivalent history; +post-merge appended commits; partial residual; renamed/reused refs; offline or +permission-incomplete inventory; duplicate/out-of-order events; provider throttling; +active PR/run/lease; dirty and ignored files; protected/release refs; malicious +repository instructions; stale proposal/actor/grant; concurrent external push; +unsupported atomic delete; archive failure; lost acknowledgement/partial cleanup; +restart without duplicate command; no Mission for inspection; residual requiring +real governance; valid own-finalizer lease versus conflicting owner; no evidence +downgrade of successful delivery; and scope-correct release preflight. Shared +versioned fixtures must qualify both producer facts and consumer meaning before +activation. New protocol routes/tables are future owning implementation work, +not invented here. + +## Source baseline for this documentation decision + +Original source reading on 2026-09-08: Forge +`d88180d2ad934cfd8ff2cc7209cf49de8c2baa88`, EP +`d1ac70e76d00fd9cb838ca12625830967402e45f`, Workspace +`4277d5c179972f22da5c6304aa068752ea8ed19d`, Forge Platform +`863d543d470c653d4360c206692c432d514160a9`. These are historical document/source +pins, not installed-product or current-host observations. Final reviewed heads, +base compatibility and merge evidence are recorded in the coordinated PR closure. diff --git a/docs/roadmap/PROJECT_HYGIENE_V1.md b/docs/roadmap/PROJECT_HYGIENE_V1.md new file mode 100644 index 0000000..f2ab491 --- /dev/null +++ b/docs/roadmap/PROJECT_HYGIENE_V1.md @@ -0,0 +1,97 @@ +# Project Hygiene V1 — scoped roadmap and documentary DAG + +Increment: `PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION_V1`. +Architecture: [Project Hygiene and Repository Reconciliation](../architecture/PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION.md). +Parent strategic authority: [Forge Roadmap](../../knowledge/bootstrap/10_ROADMAP.md). +Machine-readable companion: [project-hygiene-v1.json](project-hygiene-v1.json). + +This is a documentary capability DAG, not runtime configuration or execution +permission. On proposal branches the design is PENDING_PR; owning merges make +it canonical direction, not implemented/installed capability. All implementation, +consumer, UI and qualification nodes below remain PLANNED. Existing generic +development contracts, active programme graphs, grants and budgets are unchanged. + +## Capability sequence + +| Node | Owner | Deliverable and proof | Depends on | Status | +| --- | --- | --- | --- | --- | +| HY-0 | Forge / EP / Workspace / Forge Platform | Coordinated architecture, authority split and scoped roadmap | — | DOCUMENTATION_ONLY | +| HY-E | EP | Versioned bounded repository/host observations; freshness, scope, incomplete inventory and no mutation proof | HY-0 | PLANNED | +| HY-F | Forge | Project Context provenance projection, post-EA/provider delta refresh, bounded periodic/on-demand scans and durable cases without Mission allocation | HY-E | PLANNED | +| HY-S | Forge | Bounded evidence/intent reconciliation, explicit uncertainty, residual routing and no model-only deletion | HY-F | PLANNED | +| HY-C | EP | Reused finalizer safety plus typed scoped maintenance admission, conditional mutation, retention, idempotent per-target receipts and partial recovery | HY-E | PLANNED | +| HY-Q | Forge / EP | Shared fixtures and end-to-end observation -> case -> governed request -> EP receipt -> case reconciliation; race/lost-ack/ignored-file negatives | HY-F, HY-S, HY-C | PLANNED | +| HY-WC | Workspace | Role-aware health/chat/decision consumer contracts; no client/provider execution authority | HY-0 | PLANNED | +| HY-WO | Workspace | Read-only Repository Health/chat from qualified scoped observations and cases; stale/partial coverage and no implicit Mission | HY-WC, HY-F | PLANNED | +| HY-WM | Workspace | Scoped cleanup proposals, real owner gates and per-target outcome/history UI, with stale confirmation and cancel proof | HY-WO, HY-Q | PLANNED | +| HY-P | Forge Platform | Qualified composition/activation boundaries where hygiene is consumed; source-specific assessment, artifact retention and no installer cleanup bypass | HY-Q | PLANNED | + +```text +HY-0 -> HY-E -> HY-F -> HY-S +HY-E -> HY-C +HY-0 -> HY-WC +{HY-WC, HY-F} -> HY-WO +{HY-F, HY-S, HY-C} -> HY-Q +{HY-WO, HY-Q} -> HY-WM +HY-Q -> HY-P +``` + +Braces mean AND-dependencies. The table, graph and JSON describe the same 10 +nodes and 13 edges. HY-C reuses and strengthens existing own-run cleanup rather +than creating a second finalizer. Its standalone path does not require Forge +semantic analysis. The finalizer retains its own valid coordination lease while +cleaning proven-delivered resources; only a conflicting owner is disqualifying. +HY-WO can ship read-only without HY-C/HY-Q/HY-WM; unavailable deletion must not +block useful observation. HY-Q qualifies the full governed cleanup roundtrip, +not just the read-only slice. HY-P qualifies only the features actually included +in a composition and does not require a Workspace client. + +## Rollout and existing programme alignment + +The smallest practical increment is HY-E/HY-F: deterministic observations and +read-only case/diagnostic projection. A bounded subset can be chosen as product +work in an already governed Mission/canary. That does not implement the full +scanner, semantic analyzer or destructive-maintenance capability. + +After a successful first canary, reuse the delivered read-only subset where +present, then complete HY-E/HY-F before adding semantic HY-S or destructive +HY-C/HY-Q. Workspace HY-WC contract work can proceed in parallel; HY-WO consumes +qualified read-only facts without waiting for cleanup UI. These lanes may run +alongside the existing cross-repository Action DAG milestone: neither is a new +mandatory predecessor of the other. The first canary is not claimed complete +by this documentation or by one manual branch reconciliation. + +Scheduled project-wide observation and semantic escalation follow actual +contract/resource readiness. Require finite per-project budgets, durable cursors, +permission/freshness-aware inventories and no second Mission/Action scheduler. +Use product-owned policy services and granted operation scopes as qualified; +do not require completion of the entire POL/GP management UI for a bounded +profile, and do not infer activation from a documentary policy reference. + +Automatic cleanup remains disabled until the relevant HY-C/HY-Q proof, scoped +policy activation, actual actor authority and retained recovery requirements +exist. Workspace or an LLM cannot manufacture those capabilities. A true product +residual follows normal approved Mission/intake; case creation itself is not +product work authorization. + +This sub-DAG adds **no new predecessor** to the first serial Forge/EP autonomy +canary, wheel publication or every release. Existing EP repository safety still +applies. A concrete conflict relevant to the selected source/operation may block +that operation; unrelated old branches and optional unknown inventory do not. +No changes are made to the executable bootstrap JSON/node set or live grants. + +## Closure evidence and reference scenario + +Future implementation must separately record source tests, installed capability, +actual provider integration and activation. A manual branch cleanup is historical +example evidence, not HY-E/HY-Q qualification. The ep-producer-completion example +pins six intents to the selected main and preserves `.engineering`; it proves +nothing about every other branch or a future same-name ref. + +Each completed node needs its owning PR/source, supported contract revisions, +positive and negative tests, scope, remaining exclusions and exact qualification +receipts. Documentation merges close HY-0 only as documentation delivery; they +leave the implementation nodes PLANNED. + +Coordinated owning PRs: Forge #59, EP #108, Workspace #17 and Forge Platform #20. +Only their actual merges establish the four-product documentation closure. diff --git a/docs/roadmap/project-hygiene-v1.json b/docs/roadmap/project-hygiene-v1.json new file mode 100644 index 0000000..15453c0 --- /dev/null +++ b/docs/roadmap/project-hygiene-v1.json @@ -0,0 +1,23 @@ +{ + "document_kind": "ARCHITECTURE_ROADMAP_DAG", + "schema_version": "1.0", + "increment_id": "PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION_V1", + "execution_authority": false, + "runtime_configuration": false, + "implementation_status": "PLANNED", + "semantic_contract": "docs/architecture/PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION.md", + "parent_roadmap": "knowledge/bootstrap/10_ROADMAP.md", + "first_canary_blocker": false, + "nodes": [ + {"id": "HY-0", "owners": ["forge", "engineering-platform", "workspace", "forge-platform"], "kind": "documentation", "depends_on": [], "status": "DOCUMENTATION_ONLY"}, + {"id": "HY-E", "owners": ["engineering-platform"], "kind": "observation_contract", "depends_on": ["HY-0"], "status": "PLANNED"}, + {"id": "HY-F", "owners": ["forge"], "kind": "implementation", "depends_on": ["HY-E"], "status": "PLANNED"}, + {"id": "HY-S", "owners": ["forge"], "kind": "implementation", "depends_on": ["HY-F"], "status": "PLANNED"}, + {"id": "HY-C", "owners": ["engineering-platform"], "kind": "maintenance_execution", "depends_on": ["HY-E"], "status": "PLANNED"}, + {"id": "HY-Q", "owners": ["forge", "engineering-platform"], "kind": "qualification", "depends_on": ["HY-F", "HY-S", "HY-C"], "status": "PLANNED"}, + {"id": "HY-WC", "owners": ["workspace"], "kind": "consumer_contract", "depends_on": ["HY-0"], "status": "PLANNED"}, + {"id": "HY-WO", "owners": ["workspace"], "kind": "read_only_ui", "depends_on": ["HY-WC", "HY-F"], "status": "PLANNED"}, + {"id": "HY-WM", "owners": ["workspace"], "kind": "governed_mutation_ui", "depends_on": ["HY-WO", "HY-Q"], "status": "PLANNED"}, + {"id": "HY-P", "owners": ["forge-platform"], "kind": "composition_qualification", "depends_on": ["HY-Q"], "status": "PLANNED"} + ] +} diff --git a/knowledge/bootstrap/10_ROADMAP.md b/knowledge/bootstrap/10_ROADMAP.md index 554d79b..d1536b1 100644 --- a/knowledge/bootstrap/10_ROADMAP.md +++ b/knowledge/bootstrap/10_ROADMAP.md @@ -4,6 +4,29 @@ This is Forge's canonical strategic roadmap. Roadmap presence does not authorize execution; bounded Engineering Intents/Missions and governance remain required. Forge evolves capability-first while preserving repository-first knowledge, human governance and execution-host independence. +## Project Hygiene and Repository Reconciliation — documented target + +`FORGE::PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION_V1` extends Project +Intelligence with scoped post-EA/provider delta observations, bounded periodic +and on-demand scans, a source-backed Branch Provenance Ledger and reconciliation +cases. See the [architecture](../../docs/architecture/PROJECT_HYGIENE_AND_REPOSITORY_RECONCILIATION.md), +[scoped roadmap](../../docs/roadmap/PROJECT_HYGIENE_V1.md) and +[documentary DAG](../../docs/roadmap/project-hygiene-v1.json). + +Local sequence: EP `HY-E` observations -> Forge `HY-F` cases/projections -> +`HY-S` semantic/residual reasoning; EP `HY-C` reuses safe cleanup primitives; +`HY-Q` joins their contracts. Workspace read-only `HY-WO` need not wait for +mutation UI `HY-WM`; Forge Platform `HY-P` preserves release/install authority. +All implementation/qualification nodes remain PLANNED. This changes no executable +programme graph, live grant, package version or installed runtime. + +EP own-run cleanup is not a Mission. A Forge reconciliation case is not a Mission +or execution authorization either; genuine residual product work follows existing +governed engineering intake. Semantic equivalence alone never authorizes deletion. +Protected/active/unknown-owned work and untracked/ignored runtime data are retained. +Only relevant source/operation conflicts block a release: neither this full +capability nor deletion of unrelated old branches is a new first-canary gate. + ## Policy governance and native release management — documented target The coordinated `POLICY_GOVERNANCE_AND_EFFECTIVE_PROFILES_V1` increment defines