# Execution Plan: Repository Protocol Core Date: 2026-08-10 ## Status Completed. ## Outcome `repository-harness` has one current product: a small repository protocol plus the safe `harness` installer/updater. The optional SQLite control plane, protocol-v1 implementation, reconstruction state, and their release train no longer live in the main product repository. Release readiness is proved by fresh installation, fresh-agent repository navigation, and safe update and recovery behavior. A full consumer application runtime loop remains useful research, but is not a release gate or a current product claim. ## Context - The user explicitly authorized the strong simplification on 2026-08-10. - `docs/decisions/0019-repository-centered-default-workflow.md` established Git-native repository authority. - `docs/decisions/0024-rust-harness-core-maintenance-cli.md` established the independent `harness` maintenance product. - `docs/decisions/0025-latest-release-self-update-and-human-directed-conflicts.md` defines the updater's safety and recovery contract. - Decisions `0022` and `0023` preserved protocol v1 during a compatibility runway. This change ends that runway in this repository; Git history and the last published compatibility release preserve the former implementation. ## Scope In scope: - Remove `harness-cli` from the Rust workspace and source tree. - Remove SQLite schemas, tracked snapshots and changesets, compatibility installers, release workflows, reconstruction scripts, and dependent tests. - Remove or archive current-tree documentation whose only authority is the superseded control plane or migration history. - Rewrite current product, architecture, test, contribution, release, and installation guidance around `harness` alone. - Replace the application-runtime completion gate with three owned proofs: fresh install, fresh-agent navigation/authority behavior, and safe updater lifecycle. Out of scope: - Creating or publishing an external archive repository. - Publishing a release, changing GitHub releases, or migrating an external Symphony deployment. - Claiming that Harness can operate arbitrary consumer applications end to end. - Rewriting the proven `harness` updater architecture without evidence of a defect. - Modifying the user's pre-existing `.gitignore` change. ## Approach Make one coherent source-tree cut rather than retaining adapters between old and new ownership. First freeze the exact removal inventory and successor decision. Remove compatibility implementation and callers together. Then rewrite the surviving indexes and validation entry point, add the three owned proof boundaries, and run the complete surviving suite from a deterministic checkout state. ## Risks And Recovery - Removing protocol v1 breaks consumers that still download `harness-cli` from this repository. Mitigation: decision 0027 explicitly ends support, records `harness-cli-v0.1.22` as the last published release, and keeps installation and updates from deleting consumer-owned legacy files. - Broad deletion can remove a test that also protects the core. Mitigation: classify tests by observable owner and retain or rewrite mixed core tests before deletion. - Documentation can retain dead links and legacy terminology. Mitigation: run link/authority contracts and repository-wide reference searches. - Recovery before merge is `git switch main`; after merge it is reverting this atomic change or restoring the compatibility implementation from the last tagged release. No historical rows are rewritten. ## Progress - [x] Create `refactor/repository-protocol-core` without touching the existing `.gitignore` edit. - [x] Record the successor architecture decision and exact removal inventory. - [x] Remove compatibility source, state, release, installer, and tests. - [x] Rewrite current documentation and validation. - [x] Add or retain the three owned proof boundaries. - [x] Run focused and full validation. - [x] Obtain independent stable-candidate review and resolve findings. ## Decisions - 2026-08-10: Treat the compatibility cut as one integration boundary. Keeping a second transitional implementation in this repository would preserve the maintenance cost the change is intended to remove. - 2026-08-10: Git history and the last released artifact preserve historical implementation; the current tree will not duplicate it under a `legacy/` directory. - 2026-08-10: Full consumer runtime operation becomes explicitly bounded research. Current release claims cover only capabilities owned and tested by Harness. - 2026-08-10: The product owner explicitly selected protocol-v1 EOL instead of migration to Symphony. Decision 0027 records the breaking compatibility boundary and last published release. ## Validation - Focused proof: core Rust tests; installer profiles; update conflict, rollback, identity, and recovery tests; workflow and task-authority tests. - Integration proof: fresh install contains only the declared core and a fresh agent can navigate authority without a legacy CLI/database prerequisite. - Repository-required checks: the simplified `scripts/validate-premerge.sh`, documentation/reference contracts, `cargo fmt`, `cargo test`, `cargo clippy`, shell syntax, PowerShell installer CI contract, and `git diff --check`. Observed on 2026-08-10: - `scripts/validate-premerge.sh` passed, including 30 Rust lifecycle tests, Clippy, Bash installation, manifest, workflow, documentation, release inventory, release identity, and post-merge recovery contracts. - `cargo metadata --no-deps --format-version 1` listed only `harness`. - An independent stable-candidate review reran the complete pre-merge contract in an isolated copy and found no Rust lifecycle, Bash installer, or release workflow regression. - The review found two documentation consistency defects: decision 0026 still described two profiles, and the real-world issue template linked two deleted documents. Both were corrected and covered by the documentation contract. - PowerShell runtime execution was unavailable locally; the Windows pre-merge job remains the platform-owned execution proof. ## Result Protocol v1 is explicitly EOL under decision 0027. The Rust workspace, install paths, CI, release automation, current documentation, and validation now expose only the repository protocol and safe `harness` installer/updater. Historical source remains in Git, while installers and updates preserve pre-existing consumer-owned legacy files instead of deleting them.