# 0027 End Protocol V1 And Focus The Repository Protocol

Date: 2026-08-10

## Status

Accepted. Implementation is active on
`refactor/repository-protocol-core`.

## Context

The repository-centered workflow and the independent Rust `harness` updater
are now the product. The optional `harness-cli` still implements the earlier
SQLite lifecycle and machine protocol v1. Keeping that implementation in the
same workspace makes every product change carry its schemas, snapshots,
changesets, release automation, installer profile, historical story packets,
and approximately 18,000 lines of compatibility Rust.

Decisions 0022 and 0023 intentionally retained protocol v1 while Symphony and
explicit CLI users depended on it. That runway achieved a safe separation, but
it also left the current repository maintaining two products with different
sources of truth. On 2026-08-10 the product owner explicitly chose protocol-v1
end of support rather than another cross-repository migration.

The repository release pointer reached `harness-cli-v0.1.23`, but the last
published immutable GitHub release is `harness-cli-v0.1.22`. The published
release and prior Git tags preserve the supported historical implementation;
the unpublished pointer does not define a release that consumers can depend
on.

## Decision

1. Protocol v1 and the optional SQLite control plane are end-of-life.
2. `repository-harness` will build and publish only the `harness` binary.
3. The current tree removes `harness-cli`, schemas, tracked database state,
   changesets, compatibility installers, protocol contracts, compatibility
   release automation, and tests whose only owner was that surface.
4. Historical source remains available through Git history. Existing consumers
   may pin the last published `harness-cli-v0.1.22` release, but it receives no
   new features, fixes, or compatibility guarantee from the current product.
5. Harness installation and updates do not delete a consumer's existing
   `harness-cli` binary, `harness.db`, schemas, or other legacy files. Those
   bytes are consumer-owned after EOL and require an explicit local migration
   or removal decision.
6. The active product claim is limited to a repository protocol and its safe
   installer/updater. Release evidence covers fresh installation,
   repository-navigation and authority behavior, and update/conflict/recovery.
7. A full consumer application runtime loop remains useful research. It is not
   a release gate and is not implied by the phrase “agent-ready repository.”
8. Decisions 0021, 0022, and 0023 are superseded. Their historical rationale
   remains in Git rather than in the current documentation tree.

## Alternatives Considered

1. **Move protocol v1 into Symphony before cleanup.** Rejected by the product
   owner because the protocol is no longer part of the chosen product outcome.
   Symphony may independently adopt or replace its pinned dependency.
2. **Keep `harness-cli` in maintenance mode indefinitely.** Rejected because
   its source, data, release, installer, and validation surfaces continue to
   dominate maintenance even when no features are added.
3. **Move compatibility files under a `legacy/` directory.** Rejected because
   the old commands would remain searchable, buildable, linkable, and subject
   to current-tree maintenance. Git tags already provide an immutable archive.
4. **Require a full consumer runtime experiment before simplifying.** Rejected
   because application runtime, credentials, fixtures, logs, and cleanup are
   consumer-owned. They cannot be an honest release gate for capabilities
   Harness does not own.

## Consequences

Positive:

- The source tree, Rust workspace, installers, CI, and release train represent
  one product.
- Local validation no longer depends on an ignored SQLite database or tracked
  reconstruction state.
- Agents encounter current repository guidance instead of a second historical
  lifecycle.
- Validation claims are limited to behavior the product can reproduce.

Tradeoffs:

- Protocol-v1 consumers receive no post-`v0.1.22` maintenance from this
  repository.
- Symphony installations that need new protocol behavior must own a migration
  or replacement.
- Old databases remain readable only with a pinned historical binary or an
  independently maintained export path.
- This is a breaking product-line decision and requires explicit release notes.

## Verification

- `cargo metadata` lists only the `harness` package.
- Fresh Bash and PowerShell installs expose no compatibility flags, schemas,
  database rules, or `harness-cli` artifact.
- Pre-merge and core release workflows do not install SQLite, bootstrap a
  database, build a compatibility binary, or publish compatibility assets.
- Focused install, navigation/authority, update, conflict, rollback, recovery,
  checksum, and release-identity tests pass.
- Current-tree references to protocol v1 remain only in this EOL decision,
  migration/release notes, and immutable changelog history.