Plan: Durable Stable Baseline Promotion

Initial Situation

The API currently combines verified GitHub release inventory with nine deployment-scoped DP_BASELINE_* identity values. The uncommitted publisher workaround rewrites every value, forces an unchanged production deployment, and then verifies that deployment. This makes publication and promotion separate, non-atomic operations and caused issue #94 when the published stable release moved without the deployment witness moving with it.

IP-323 already owns release selection, exact-version behavior, immutable identity, artifact verification, and typed fail-closed errors. This successor changes only the moving stable-authority persistence and publication lifecycle.

Problem Statement

A successful verified stable publication must atomically become production stable authority without rewriting baseline identity environment values or redeploying the API. The authority must be shared across serverless instances, preserve append-only history and rollback, reject stale or conflicting promotions, and remain verifiable against immutable GitHub evidence.

Proposed Solution Shape

Add an immutable baseline_release table and append-only stable_baseline_promotion ledger to the existing Postgres runtime. The stable pointer is the latest committed ledger revision. A dedicated baseline-promotion endpoint authenticates only a publisher machine credential, verifies the candidate against GitHub evidence, and commits immutable release identity plus the next revision in one advisory-locked transaction. Stable reads load the current revision at request time and verify that exact release; exact-version reads remain independent of the moving pointer. baseline:publish uploads and verifies release assets, calls the promotion endpoint, then confirms the stable readback. It never writes Vercel baseline identity or starts a deployment.

Resolved Decision Ledger

Assumptions and Constraints

• Preserve the dirty worktree. Do not edit dirty package manifests or bun.lock; no new dependency is required.
• Keep the separate five-second CLI authority timeout repair already present in apps/cli/src/baseline/resolve.ts and its test.
• Never log, echo, persist, or return the publisher credential. Compare it in constant time and redact configuration.
• Provider I/O occurs before or after, never inside, the database transaction.
• Database bigint revisions cross package/API boundaries as decimal strings.
• A same-canonical-release retry returns the original logical revision after exact immutable-field comparison, even if its expected revision is stale.
• A different candidate must satisfy CAS when supplied and IP-323 newest ordering. Equal publication time uses the existing canonical release-ID tie-break.
• Only explicit rollback mode may target an older previously committed release; it requires expected current revision and a nonblank reason. Normal publish mode remains newest-only.
• Initial production cutover seeds the currently active verified release before the DB-backed reader is deployed. There is no empty-ledger fallback to environment identity.
• Removing obsolete production identity values happens only after durable readback succeeds.
• Workers that touch an already-dirty path must capture its pre-edit diff, preserve unrelated hunks, and use surgical patches rather than replacing the file wholesale.
• Existing dirty integration inputs owned by this delivery are apps/cli/scripts/publish-baseline.mjs, untracked apps/cli/scripts/promote-baseline-authority.mjs, apps/cli/src/baseline/baseline-release-scripts.test.ts, apps/cli/src/baseline/resolve.ts, apps/cli/src/baseline/resolve.test.ts, apps/cli/README.md, docs/README.md, docs/runbooks/hi-cli-scaffolding.md, and apps/wiki/content/docs/project/runbooks/hi-cli-scaffolding.md. Each path has exactly one worker owner below.

Codebase Findings

• apps/api/src/baseline-registry.ts owns IP-323 stable/exact selection and environment cross-checking.
• apps/api/src/baseline-release-inventory.ts owns immutable-conflict detection and newest ordering.
• apps/api/src/platform/runtime/application.ts currently constructs normal and download baseline paths from configuration before database resources are injected.
• apps/api/src/integrations/persistence/report-repository-drizzle.ts demonstrates transaction-scoped Postgres advisory locking.
• packages/db/src/postgres-contract.test.ts is the real-Postgres migration/contract harness.
• packages/contract/src/baseline.ts owns the baseline public protocol and typed failures.
• apps/cli/scripts/promote-baseline-authority.mjs is an uncommitted Vercel-coupled workaround to replace, not preserve.
• apps/cli/src/baseline/baseline-release-scripts.test.ts already provides a subprocess-observation seam for proving the publisher does not invoke Vercel.

External Research Used

• Vercel environment changes only affect subsequent deployments, confirming that mutable baseline identity cannot provide no-redeploy promotion.
• GitHub release assets remain evidence/artifact storage; they do not provide the independent atomic pointer, audit history, and compare-and-set behavior required here.
• Existing Postgres and Drizzle infrastructure supports transaction-scoped advisory locks without adding another provider.

Dependency Graph

[T1 contract, T2 database] -> T3 promotion service/endpoint
T3 -> [T4 runtime reads, T5 publisher, T6 CLI authority presentation]
[T4, T5] -> T7 runtime harness -> T8 verified seed -> T9 capability deployment
[T6, T9] -> T10 no-redeploy production proof -> T11 obsolete-env cleanup -> T12 docs/closeout

Parallel Execution Waves

Testing Strategy

• Contract tests first define promotion request/result, publisher authentication failure, authority conflict, integrity conflict, and availability semantics.
• Real Postgres tests prove migration repeatability, immutable releases, append-only revisions, controlled rollback history, and update/delete rejection.
• API domain tests prove idempotency, CAS, ordering, and typed failures; real Postgres runtime tests prove concurrent linearization.
• Registry tests prove stable is the committed revision, newer unpromoted GitHub evidence cannot displace it, exact selectors still work, and restart/recomposition preserves authority.
• Publisher subprocess tests prove verified assets produce one authenticated promotion request, no vercel env or vercel deploy command occurs, post-commit confirmation is explicit, and retry reconciles.
• CLI repository-check tests prove HTTP 409 remains an actionable authority defect and is never collapsed into baseline-authority-unavailable or bundled fallback.
• Final runtime proof uses a real migrated Postgres database and a running API, records deployment state before publication, publishes/promotes, reads stable/artifacts afterward, and proves deployment identity did not change.

Tasks

T1: Define the baseline-promotion protocol and publisher-only authentication failures

• depends_on: []
• location: packages/contract/src/baseline.ts; packages/contract/src/api.test.ts; packages/contract/src/public-protocol-contract.test.ts; generated protocol fixtures
• description: Add the promotion candidate, explicit publish/rollback mode, expected revision, rollback reason, committed/already-committed result, revision, audit identity, and dedicated publisher-unauthorized schemas to BaselineApi. Add POST /baselines/stable/promotions. Do not reuse Backoffice contracts or expose the credential in payloads/results.
• validation: Public protocol round-trips complete immutable identity; malformed digests/revisions fail decoding; OpenAPI exposes the promotion endpoint and its typed 401/409/422/503 errors; no Backoffice dependency appears.
• status: Completed
• log: 2026-08-03 — Test-drove the public promotion protocol. Added immutable candidate identity, strict revision/digest schemas, discriminated publish/rollback intent, committed/idempotent result, publisher-only 401, and promotion-specific 409/422/503 failures. No Backoffice dependency was introduced.
• files edited/created: packages/contract/src/baseline.ts; packages/contract/src/api.test.ts; packages/contract/src/typed-failure-contract.test.ts; packages/contract/src/public-protocol-contract.openapi.json; packages/contract/src/public-protocol-contract.openapi-semantics.json
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [codebase-design, quality-types, tdd, simplify]
• tdd_status: required
• tdd_target: The public contract cannot represent an authenticated stable promotion or its typed conflict/outcome semantics.
• red_command: bun run --cwd packages/contract test -- src/api.test.ts src/public-protocol-contract.test.ts src/typed-failure-contract.test.ts
• expected_red_failure: Promotion endpoint/schemas are absent from the public API and generated contract fixtures.
• green_command: bun run --cwd packages/contract test -- src/api.test.ts src/public-protocol-contract.test.ts src/typed-failure-contract.test.ts && bun run --cwd packages/contract check-types
• reason_not_testable:
• red_evidence: Exact RED exited 1 with five failures because the promotion route, request/result schemas, publisher unauthorized failure, and registered endpoint errors were absent.
• green_evidence: Exact GREEN passed 32/32 and contract typecheck passed. Full contract suite passed 33/33; focused Oxlint, Oxfmt, and diff check passed. Whole-package formatting remains blocked only by the pre-existing dirty out-of-scope packages/contract/package.json.
• codebase_design_notes: BaselineApi remains the protocol seam. Authentication is a promotion-specific HTTP concern, never a Backoffice domain dependency.
• review_mode: cli
• runtime_validation: not_required
• runtime_target: not_applicable
• runtime_evidence: not_applicable
• runtime_cleanup: not_applicable

T2: Add immutable release and append-only stable-promotion persistence

• depends_on: []
• location: packages/db/src/schema/baseline-authority.ts; packages/db/src/schema/index.ts; packages/db/src/migrations/0004_*.sql; packages/db/src/migrations/meta/**; packages/db/src/baseline-authority-postgres.test.ts; packages/db/src/postgres-contract.test.ts; packages/db/test-fixtures/public-schema.json
• description: Add immutable release identity and append-only promotion revision tables. Record publish versus rollback, expected/previous revision, reason, canonical release/version uniqueness, digest checks, previous/resulting identity, committed audit data, and database-level update/delete rejection. Generate the schema migration without editing package manifests or the lockfile.
• validation: A real Postgres migration creates the schema repeatably; conflicting identities fail; same identity is readable; promotions append; rollback targets an earlier immutable release; update/delete fail.
• status: Completed
• log: 2026-08-03 — Test-drove the real-Postgres ledger. Added immutable releases, append-only publish/rollback revisions, unique logical publication identity, one root/one successor per prior revision, self-referential history, and update/delete rejection triggers. Review RED exposed missing operation/chain uniqueness; the corrected migration rejects duplicate publication, root, and successor rows while allowing controlled rollback to an earlier release.
• files edited/created: packages/db/src/schema/baseline-authority.ts; packages/db/src/schema/index.ts; packages/db/src/migrations/0004_marvelous_luke_cage.sql; packages/db/src/migrations/meta/0004_snapshot.json; packages/db/src/migrations/meta/_journal.json; packages/db/src/baseline-authority-postgres.test.ts; packages/db/test-fixtures/public-schema.json
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [backend-domain-structure, codebase-design, effect-recoverable-actions, quality-types, tdd]
• tdd_status: required
• tdd_target: The migrated database lacks immutable releases, append-only stable revisions, and rollback/audit constraints.
• red_command: bun run --cwd packages/db test -- src/baseline-authority-postgres.test.ts
• expected_red_failure: Baseline authority tables/exports do not exist and append-only constraint assertions fail.
• green_command: bun run --cwd packages/db db:generate && bun run --cwd packages/db test -- src/baseline-authority-postgres.test.ts src/postgres-contract.test.ts && bun run --cwd packages/db check-types
• reason_not_testable:
• red_evidence: Initial real-Postgres RED found only the existing nine tables. Review RED later resolved a duplicate publication identity instead of rejecting it, proving DB idempotency/linear-chain constraints were absent.
• green_evidence: Parent independently reran the exact real-Postgres suite with Docker access: 2 files and 3 tests passed. db:generate reported no schema changes; typecheck, focused Oxlint/Oxfmt, and diff check passed. Whole-package formatting remains blocked only by the pre-existing dirty out-of-scope packages/db/package.json.
• codebase_design_notes: Persistence owns storage shape only. Revisions are append-only facts; current stable is derived from the latest committed revision.
• review_mode: cli
• runtime_validation: required
• runtime_target: Repository-supported Postgres container migrated through Drizzle.
• runtime_evidence: Real SQL proves migrations, immutable rows, linear revision history, rollback append, and database rejection of mutation/deletion.
• runtime_cleanup: Use the package-owned test database/container and test transaction cleanup; remove only run-owned rows/container state.

T3: Implement atomic promotion service, repository, endpoint, and scoped machine auth

• depends_on: [T1, T2]
• location: apps/api/src/features/baseline-promotion/**; apps/api/src/integrations/persistence/baseline-promotion-drizzle.ts; apps/api/src/platform/http/api.ts; apps/api/src/platform/http/authorization.ts; apps/api/src/runtime/config.ts; focused API tests
• description: Verify candidate release evidence before persistence. Authenticate Authorization: Bearer against redacted DP_BASELINE_PUBLISH_TOKEN using constant-time comparison. Under a transaction-scoped stable-channel advisory lock, reconcile identical retries, compare immutable identity, enforce CAS and IP-323 ordering for normal publication, require expected current revision plus reason for explicit rollback to a previously committed release, append one revision, and map unauthorized/authority/integrity/store failures to the contract. Never use Backoffice auth and never perform provider I/O inside the transaction.
• validation: Tests cover unauthorized/malformed auth, secret non-disclosure, same-candidate idempotency, immutable conflict, CAS conflict, stale normal candidate, equal-time tie-break, newer promotion, controlled rollback audit/refusals, concurrent linear history, and persistence failure.
• status: Completed
• log: Implemented independent published-release and manifest verification before persistence; feature policy/store port; advisory-locked Drizzle transaction adapter; scoped constant-time publisher bearer auth; typed endpoint mappings; and production runtime/config composition. Review corrections bind idempotency to the original CAS, canonicalize publication instants, and restrict rollback to a release preceding the current head. Real-Postgres concurrent linearization remains assigned to T7.
• files edited/created: apps/api/src/features/baseline-promotion/**; apps/api/src/integrations/persistence/baseline-promotion-drizzle.ts; apps/api/src/integrations/persistence/baseline-promotion-drizzle.test.ts; apps/api/src/platform/http/baseline-promotion.test.ts; apps/api/src/platform/http/api.ts; apps/api/src/platform/http/authorization.ts; apps/api/src/platform/runtime/application.ts; apps/api/src/runtime/config.ts; apps/api/src/runtime/config-contract.test.ts; apps/api/src/baseline-release-inventory.ts; apps/api/src/baseline-release-inventory.test.ts
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [effect, effect-backend-structure, effect-recoverable-actions, logging-best-practices, backend-recoverable-actions, security-best-practices, tdd]
• tdd_status: required
• tdd_target: No authenticated transaction can atomically reconcile or append a stable promotion under concurrent/stale/conflicting requests.
• red_command: bun run --cwd apps/api test -- src/features/baseline-promotion/baseline-promotion.test.ts src/integrations/persistence/baseline-promotion-drizzle.test.ts src/platform/http/baseline-promotion.test.ts
• expected_red_failure: Promotion service, store, auth seam, and endpoint do not exist.
• green_command: bun run --cwd apps/api test -- src/features/baseline-promotion/baseline-promotion.test.ts src/integrations/persistence/baseline-promotion-drizzle.test.ts src/platform/http/baseline-promotion.test.ts && bun run --cwd apps/api check-types
• reason_not_testable:
• red_evidence: Focused feature, config, HTTP, Drizzle, and publication-evidence tests first failed because the promotion service/store, publisher configuration/authentication, endpoint, persistence adapter, and exact evidence verifier did not exist.
• green_evidence: Parent independently reran the focused gate: 5 files and 66 tests passed. bun run --cwd apps/api check-types, bun run --cwd apps/api build, and git diff --check -- apps/api/src passed. Adapter coverage proves the transaction advisory lock precedes reads and a normalized legitimate retry performs no write; T7 owns the real-Postgres concurrent request proof.
• codebase_design_notes: A feature-owned service defines policy; a small store port hides Drizzle; HTTP owns credential extraction; the repository owns locking/transaction mechanics.
• review_mode: cli
• runtime_validation: required
• runtime_target: Running API backed by a real migrated Postgres database.
• runtime_evidence: Concurrent authenticated requests yield one ordered history; unauthorized requests persist nothing; request/response/log evidence contains no secret.
• runtime_cleanup: Use run-tagged release identities and delete only if the test database permits cleanup; production ledger facts are never deleted.

T4: Cut stable resolution and artifact downloads over to durable authority

• depends_on: [T3]
• location: apps/api/src/baseline-registry.ts; apps/api/src/baseline-registry.test.ts; apps/api/src/platform/runtime/application.ts; apps/api/src/platform/http/baseline-download.ts; apps/api/src/database-injection-contract.test.ts; runtime-product tests
• description: Read the latest committed stable revision on every implicit-stable resolve/artifact request, then verify that exact version against GitHub evidence and artifact digests. Preserve exact-version behavior. Inject the durable store into lifecycle-owned ordinary routes. Keep the required-version artifact download handler ahead of lifecycle initialization with an unavailable stable store because that immutable request never reads the moving pointer. Remove mutable baseline identity environment fields and their cross-check; map missing/transport failures to availability and persisted/evidence mismatch to integrity.
• validation: Fresh registry/application instances retain stable; newer unpromoted GitHub releases do not move it; exact selectors remain correct; missing/unavailable ledger fails typed and closed for stable reads; exact downloads verify the requested release without opening database/auth/backoffice resources.
• status: Completed
• log: Implicit stable now reads the latest committed ledger candidate on every request, verifies that exact candidate against GitHub release and manifest evidence, and ignores newer unpromoted inventory. Exact-version selectors remain independent verified inventory reads. Lifecycle-owned metadata, artifact metadata, and promotion share one Drizzle adapter/database. Exact artifact downloads are reconstructed before that lifecycle with an unavailable stable store and therefore depend only on baseline/server configuration plus verified release transport. Mutable baseline identity environment fields were removed while public origin, GitHub inventory configuration, and publisher token remain.
• files edited/created: apps/api/src/baseline-registry.ts; apps/api/src/baseline-registry.test.ts; apps/api/src/database-injection-contract.test.ts; apps/api/src/features/baseline-promotion/authority-read.ts; apps/api/src/features/baseline-promotion/store.ts; apps/api/src/features/baseline-promotion/testing.ts; apps/api/src/integrations/persistence/baseline-promotion-drizzle.ts; apps/api/src/integrations/persistence/baseline-promotion-drizzle.test.ts; apps/api/src/platform/http/api.ts; apps/api/src/platform/runtime/application.ts; apps/api/src/public-api-contract.test.ts; apps/api/src/runtime/config.ts; apps/api/src/runtime/config-contract.test.ts; canonical-instant comparison in apps/api/src/baseline-release-inventory.ts
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [effect, effect-backend-structure, effect-recoverable-actions, codebase-design, tdd]
• tdd_status: required
• tdd_target: Stable reads still derive authority from deployment environment or newest inventory rather than the committed ledger revision.
• red_command: bun run --cwd apps/api test -- src/baseline-registry.test.ts src/database-injection-contract.test.ts src/platform/http/baseline-download.test.ts
• expected_red_failure: No durable store is injected; restart/unpromoted-newer/missing-ledger assertions fail.
• green_command: bun run --cwd apps/api test -- src/baseline-registry.test.ts src/database-injection-contract.test.ts src/platform/http/baseline-download.test.ts && bun run --cwd apps/api check-types && bun run --cwd apps/api build
• reason_not_testable:
• red_evidence: The exact T4 test target failed because a newer published inventory release displaced the committed durable revision, proving implicit stable still followed inventory instead of ledger state.
• green_evidence: Parent reran the exact gate: 3 files and 30 tests passed. An expanded impacted API gate passed 9 files and 108 tests. API typecheck, build, and git diff --check -- apps/api/src passed. Fresh construction, missing/store failures, unpromoted-newer evidence, exact selectors, durable evidence mismatch, both artifact paths, and one-store lifecycle injection are covered; T7 retains the real-Postgres process reconstruction proof.
• codebase_design_notes: BaselineRegistry consumes a durable authority-read port for moving-pointer reads. Lifecycle composition injects one database-backed implementation into ordinary routes. The exact-download fast path injects an unavailable implementation intentionally because the required version bypasses readLatest; inventory remains evidence, not pointer state.
• review_mode: cli
• runtime_validation: required
• runtime_target: Reconstructed API process against persisted Postgres state and controlled GitHub inventory evidence, plus exact-download startup with database/auth/backoffice unavailable.
• runtime_evidence: Stable identity survives process reconstruction; a newer unpromoted candidate is ignored; exact selection and artifact bytes/digests remain verified without lifecycle resource initialization.
• runtime_cleanup: Use run-owned test releases/state in the runtime harness; preserve durable production history.

T5: Replace Vercel promotion with one authenticated API commit in the publisher

• depends_on: [T3]
• location: apps/cli/scripts/publish-baseline.mjs; apps/cli/scripts/promote-baseline-authority.mjs; apps/cli/src/baseline/baseline-release-scripts.test.ts; apps/cli/README.md
• description: Capture the pre-edit diffs for all four owned dirty paths, then surgically replace the uncommitted Vercel env/deploy workaround with verified GitHub release discovery plus an authenticated promotion request using DP_BASELINE_PUBLISH_TOKEN and the control-plane origin. Confirm stable readback after commit. Make post-commit confirmation failure explicit and retry-safe. Remove Vercel link checks, nine env writes, and deployment commands while preserving unrelated hunks.
• validation: Subprocess/fetch fixtures prove exact release identity and digests are sent, auth is present but never printed, same-release retry reconciles, readback must match, and no Vercel mutation/deploy command can execute.
• status: Completed
• log: Replaced the uncommitted Vercel project-link, nine-environment-write, and forced-deployment flow with exact gh release view evidence, deterministic baseline-release:<releaseId> idempotency, one bearer-authenticated promotion POST, and stable plus manifest/archive metadata confirmation. Post-commit confirmation failure is reported as indeterminate and retry-safe with the same identity; the publisher token is absent from payloads and output. Review corrections make interrupted zero/partial-asset releases recover by uploading only missing assets, keep complete releases mutation-free, refuse present mismatches/duplicates/malformed URLs, compare promotion candidates structurally, and require HTTPS except explicit loopback HTTP.
• files edited/created: apps/cli/scripts/publish-baseline.mjs; apps/cli/scripts/promote-baseline-authority.mjs; apps/cli/scripts/promote-baseline-authority.d.mts; apps/cli/src/baseline/baseline-release-scripts.test.ts; issue-94 publishing hunk in apps/cli/README.md
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [tdd, quality-types, logging-best-practices, security-best-practices, simplify]
• tdd_status: required
• tdd_target: Publisher currently mutates nine Vercel values and forces deployment instead of committing runtime authority through the API.
• red_command: bun run --cwd apps/cli test -- src/baseline/baseline-release-scripts.test.ts
• expected_red_failure: New no-Vercel/authenticated-promotion assertions observe Vercel env/deploy commands and no promotion HTTP request.
• green_command: bun run --cwd apps/cli test -- src/baseline/baseline-release-scripts.test.ts && bun run --cwd apps/cli check-types && bun run --cwd apps/cli build
• reason_not_testable:
• red_evidence: The new publisher tests initially failed three cases at the obsolete requireLinkedApiProject boundary because .vercel/project.json was absent, directly proving promotion still depended on Vercel deployment state.
• green_evidence: Parent independently reran the corrected focused publisher suite: 12/12 passed. bun run --cwd apps/cli check-types, bun run --cwd apps/cli build, the full CLI check, scoped diff checks, and a source scan proving no Vercel capability in publisher code passed.
• codebase_design_notes: The script orchestrates build/upload/promotion; verification helpers remain pure/testable and credentials stay at the HTTP boundary.
• review_mode: cli
• runtime_validation: required
• runtime_target: Publisher against a running API and controlled GitHub release evidence.
• runtime_evidence: One publication yields a committed ledger revision and matching stable/artifact readback while a command/deployment observer records zero Vercel env/deploy operations.
• runtime_cleanup: Use a run-owned candidate in non-production proof; do not delete committed production history or unrelated releases.

T6: Preserve actionable CLI authority disagreements

• depends_on: [T3]
• location: apps/cli/src/baseline/resolve.ts; apps/cli/src/baseline/resolve.test.ts; apps/cli/src/features/repository-check/application.ts; focused repository-check/public-output tests if required
• description: Capture both existing dirty diffs, preserve the separate five-second timeout repair, and test-drive the remaining IP-323 presentation requirement: an HTTP 409 BaselineAuthorityFailure remains an actionable authority defect in hi check --json, with its message intact, no baseline-authority-unavailable degradation, and no bundled fallback.
• validation: Focused resolver and repository-check JSON assertions distinguish 409 authority failure from network/availability failures while preserving the existing timeout behavior.
• status: Completed
• log: The resolver already preserved HTTP 409 BaselineAuthorityFailure messages and disabled bundled fallback. The actual defect was repository-check allowing an outer remote-access reason to outrank the nested typed authority cause; classification now gives the authority defect precedence while preserving genuine transport degradation. The independent five-second timeout repair is unchanged.
• files edited/created: apps/cli/src/baseline/resolve.test.ts; apps/cli/src/features/repository-check/application.ts; apps/cli/src/features/repository-check/application-boundary.test.ts (apps/cli/src/baseline/resolve.ts retains only its pre-existing timeout change)
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [debugging-phase, effect-recoverable-actions, quality-types, tdd]
• tdd_status: required
• tdd_target: hi check --json currently risks classifying a typed authority disagreement as transient baseline unavailability.
• red_command: bun run --cwd apps/cli test -- src/baseline/resolve.test.ts src/features/repository-check/application-boundary.test.ts
• expected_red_failure: A synthetic HTTP 409 becomes unavailable/degraded, loses its message, or enables fallback.
• green_command: bun run --cwd apps/cli test -- src/baseline/resolve.test.ts src/features/repository-check/application-boundary.test.ts && bun run --cwd apps/cli check-types
• reason_not_testable:
• red_evidence: The focused repository-check boundary test showed a nested BaselineAuthorityFailure becoming a baseline-authority-unavailable degradation with overall status degraded because the outer resolution reason was remote-access.
• green_evidence: Parent reran the resolver and repository-check boundary gate with required loopback access: 2 files and 71 tests passed. The hi check command regression suite passed 18/18. Scoped formatting/lint/diff checks passed. After T5 completed its publisher declaration, full CLI typecheck and build passed.
• codebase_design_notes: The control-plane client preserves typed protocol failures; repository-check decides presentation without converting authority/integrity defects into availability.
• review_mode: cli
• runtime_validation: not_required
• runtime_target: not_applicable
• runtime_evidence: not_applicable
• runtime_cleanup: not_applicable

T7: Implement the real-Postgres no-redeploy runtime scenario

• depends_on: [T4, T5]
• location: apps/api/scripts/validate-runtime-product.mjs; focused runtime scenario support/tests
• description: Add a run-owned local scenario that migrates a real Postgres database, starts/reconstructs the API, promotes verified controlled release evidence, reads stable and artifact metadata/bytes, observes all publisher subprocesses, and compares a stable synthetic deployment identity before/after publication. Add explicit production phases configure-deploy-seeded-readback, publish-no-redeploy, and remove-obsolete-env; each defaults to report-only, verifies the canonical Vercel project, requires --apply for mutation, consumes a caller-supplied publisher token without printing it, captures every required evidence field, and fails unless its whole checked sequence passes.
• validation: The local scenario fails before implementation, then proves persistence across API reconstruction, matching digests and exact selectors, concurrent linearization, and zero Vercel env/deploy operations. Production-phase unit tests prove exact command allowlists, project/target validation, redaction, deployment-ID comparison, ledger/artifact/readback assertions, retry idempotency, and the exact nine-name cleanup boundary without executing providers.
• status: Completed
• log: Added a real-Postgres runtime scenario plus checked production cutover phases. The scenario proves the fixed seed, revision-2 publication, concurrent CAS linearization, stable/exact metadata, artifact bytes/digests, process reconstruction, and zero Vercel commands. Production orchestration is report-only by default, validates the canonical linked project, parses actual Vercel JSON shapes, preserves typed indeterminate retry semantics without response secrets, uses a sensitive stdin-only publisher token, and keeps cleanup retryable by removing only obsolete names still present.
• files edited/created: apps/api/scripts/validate-runtime-product.mjs; apps/api/scripts/runtime-product-provider-json.mjs; apps/api/scripts/runtime-product-provider-json.d.mts; apps/api/src/runtime/baseline-ledger-cutover.ts; apps/api/src/runtime/baseline-ledger-cutover.test.ts; apps/api/src/runtime/baseline-ledger-no-redeploy.runtime.test.ts
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [debugging-phase, tdd, turborepo, logging-best-practices]
• tdd_status: required
• tdd_target: No supported runtime scenario proves durable promotion and unchanged deployment identity across real process/database boundaries.
• red_command: bun run --cwd apps/api validate:runtime-product -- --scenario baseline-ledger-no-redeploy
• expected_red_failure: Scenario is absent or reports environment/deployment-coupled authority.
• green_command: bun run --cwd apps/api test -- src/runtime/baseline-ledger-cutover.test.ts && bun run --cwd apps/api validate:runtime-product -- --scenario baseline-ledger-no-redeploy
• reason_not_testable:
• red_evidence:
• green_evidence: Parent reran the final gates: the real Docker/Postgres scenario passed 1/1 after the fixed seed was integrated; the cutover suite passed 15/15 including typed 503 reconciliation and retryable present-only cleanup. API typecheck/build and scoped formatting/diff checks passed. A live read-only Vercel env listing parsed 38 real metadata-bearing entries and exactly the nine obsolete names.
• codebase_design_notes: Runtime harness drives only public API/publisher seams and real persistence. Production phases are checked orchestration with report-only default and explicit apply boundary; test doubles are limited to deterministic GitHub/Vercel command evidence.
• review_mode: cli
• runtime_validation: required
• runtime_target: Repository-supported Postgres plus running API and publisher processes.
• runtime_evidence: Run ID, migrated DB revision history, pre/post process identity, stable/artifact responses and bytes, exact-selector response, and zero Vercel operations.
• runtime_cleanup: Generate a unique run ID; stop only run-owned processes/container and remove only run-owned temporary release evidence and database rows where the test database permits it.

T8: Seed the verified current authority before reader cutover

• depends_on: [T2, T4, T7]
• location: packages/db/src/migrations/0004_*.sql or immediately following fixed data migration; packages/db/src/baseline-authority-postgres.test.ts; release-evidence record in implementation notes
• description: Independently resolve the current production stable release ID, version/tag, publication time, commit, provenance, compatibility range, asset URLs, and SHA-256 digests from GitHub. Add an idempotent fixed seed for release plus revision 1. Never read seed identity from runtime env. Test exact values and conflict refusal in real Postgres.
• validation: GitHub evidence and migration constants agree byte-for-byte; repeated migration is stable; a different row under the same release/version fails rather than overwriting.
• status: Completed
• log: Added fixed data migration 0006 for the independently verified current production stable release and root revision 1. The migration inserts only for an empty ledger, accepts an exact preexisting seed identity, refuses conflicting ledger/release identities, and advances the revision sequence for the next promotion.
• files edited/created: packages/db/src/migrations/0006_seed_stable_baseline_authority.sql; packages/db/src/migrations/meta/_journal.json; packages/db/src/baseline-authority-postgres.test.ts
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [tdd, quality-types, logging-best-practices]
• tdd_status: required
• tdd_target: A clean migrated database has no verified initial stable revision and the reader would fail closed at first deployment.
• red_command: bun run --cwd packages/db test -- src/baseline-authority-postgres.test.ts -t "seeds the verified production authority"
• expected_red_failure: No seed row/revision exists or its immutable tuple differs from independently captured GitHub evidence.
• green_command: bun run --cwd packages/db test -- src/baseline-authority-postgres.test.ts src/postgres-contract.test.ts && bun run --cwd packages/db check-types
• reason_not_testable:
• red_evidence:
• green_evidence: Authenticated GitHub release and manifest readback reverified release ID 362549177, publication time, tag/version, commit, compatibility range, asset IDs/URLs, and both SHA-256 digests. Parent reran the real-Postgres gate: 2 files and 6 tests passed, including zero-to-latest, repeated seed, conflict refusal, sequence continuation, append-only publish/rollback, plus DB typecheck.
• codebase_design_notes: The fixed seed is one-time bootstrap data inside migration history, never runtime fallback configuration.
• review_mode: cli
• runtime_validation: required
• runtime_target: Clean repository-supported Postgres migrated from zero.
• runtime_evidence: Release evidence record plus SQL readback of exact revision 1 on first and repeated migration.
• runtime_cleanup: Test database only; production seed remains immutable audit history.

T9: Deploy the ledger capability once and verify seeded production readback

• depends_on: [T4, T5, T8]
• location: production Postgres migration state; Vercel API project configuration/deployment; evidence recorded in implementation notes
• description: Generate a strong publisher token outside logs, configure only DP_BASELINE_PUBLISH_TOKEN, migrate production Postgres before traffic moves to the new reader, deploy the API capability once, and verify seeded stable plus both artifact paths. Do not remove old identity values yet.
• validation: Migration revision and seeded tuple read back first; the new deployment returns the same verified stable identity/artifacts; token value is absent from command output and artifacts.
• status: Completed
• log: Migrated and seeded production with 2026.07.30-security-pack at durable revision 1. Verified manifest digest a324..., archive digest febf..., and seeded stable/artifact readback. Configured only the publisher capability and completed the one required deployment at dpl_CVSWHsq8bDiE7MCSv7tPE5JrCzRf after correcting the secret transport to preserve the exact stdin bytes. No credential value was logged or persisted in delivery artifacts.
• files edited/created: No repository implementation files; production migration/configuration/deployment state and IMPLEMENTATION-NOTES.md evidence only.
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [debugging-phase, security-best-practices, logging-best-practices]
• tdd_status: not_applicable
• tdd_target: not_applicable
• red_command: not_applicable
• expected_red_failure: not_applicable
• green_command: bun run --cwd packages/db db:migrate && bun run --cwd apps/api validate:runtime-product -- --scenario baseline-ledger-cutover --phase configure-deploy-seeded-readback --apply
• reason_not_testable: This task applies already-tested migration/code and a secret to production; completion is external readback, not new behavior implementation.
• red_evidence:
• green_evidence: Production revision 1 returned 2026.07.30-security-pack with manifest a324... and archive febf...; capability deployment dpl_CVSWHsq8bDiE7MCSv7tPE5JrCzRf completed after exact secret-stdin correction, with no secret value captured.
• codebase_design_notes: Migration precedes reader deployment. Only a static scoped credential is added; baseline identity remains out of deployment configuration.
• review_mode: mixed
• runtime_validation: required
• runtime_target: Production Postgres and the canonical Vercel API project.
• runtime_evidence: Migration ID/readback, Vercel deployment ID, HTTP 200 stable response, manifest/archive proxy responses and verified digests, redacted secret configuration confirmation.
• runtime_cleanup: Preserve deployment and ledger audit evidence; do not expose/retrieve the secret value; old identity env values remain until T11.

T10: Prove production publication changes authority without deployment

• depends_on: [T6, T9]
• location: production GitHub release, promotion ledger, stable/artifact endpoints, Vercel deployment metadata; evidence recorded in implementation notes
• description: Capture the active API deployment ID, run the verified publication workflow with a clean release provenance, capture its committed promotion revision, confirm stable and artifact identity/digests plus hi check --json, then capture deployment ID again. Observe that the publisher executed no Vercel env/deploy command.
• validation: The promoted release equals GitHub evidence and API readback; hi check --json is actionable/healthy as applicable; before/after deployment IDs match; ledger revision advances once; retry returns the same revision.
• status: Completed
• log: Published baseline/stable/2026.08.03-durable-stable-authority-v2 from commit c910c9edf656e96d7b818e9ff052dd5cc2b50a1f. GitHub release database ID 364190218 carried manifest digest 6095... and archive digest f7e4.... The publisher completed twice with exit 0, reconciling the retry to durable revision 2. Stable and both artifact endpoints returned HTTP 200 while the production deployment remained dpl_CVSWHsq8bDiE7MCSv7tPE5JrCzRf. The merged CLI 3.1 hi check resolved v2 and reported the expected drift-detected result without authority-unavailable degradation.
• files edited/created: BASELINE_CHANGELOG.md; deterministic publisher/build regression coverage and release bookkeeping already captured by the implementation commits; IMPLEMENTATION-NOTES.md evidence.
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [debugging-phase, logging-best-practices, security-best-practices]
• tdd_status: not_applicable
• tdd_target: not_applicable
• red_command: not_applicable
• expected_red_failure: not_applicable
• green_command: bun run --cwd apps/api validate:runtime-product -- --scenario baseline-ledger-cutover --phase publish-no-redeploy --apply
• reason_not_testable: This is live acceptance proof of already-test-driven behavior across GitHub, Postgres, Vercel, API, and CLI boundaries.
• red_evidence:
• green_evidence: Release ID 364190218, v2 tag, commit c910c9edf656e96d7b818e9ff052dd5cc2b50a1f, manifest 6095..., archive f7e4..., two publisher exit-0 runs, durable revision 2, three HTTP 200 authority/artifact readbacks, unchanged deployment ID, and CLI 3.1 drift-detected without authority unavailability. A live exact idempotent POST directly returned HTTP 200 with outcome: already-committed, revision 2, previous revision 1, previous release ID 362549177, committed at 2026-08-03T12:16:58.981Z, for publication identity baseline-release:364190218.
• codebase_design_notes: Publication uses GitHub as evidence and the promotion API as the only moving authority mutation.
• review_mode: mixed
• runtime_validation: required
• runtime_target: Production publisher, Postgres ledger, API, CLI, and deployment metadata.
• runtime_evidence: Release tuple, promotion revision/readback, exact stable/artifact responses, fresh hi check --json, identical pre/post deployment IDs, and command trace with zero Vercel mutation/deploy operations.
• runtime_cleanup: Preserve the legitimate published release and append-only ledger; remove only run-owned temporary files and redact credentials.

T11: Remove obsolete production baseline identity environment values

• depends_on: [T10]
• location: canonical Vercel API project's production environment configuration; evidence recorded in implementation notes
• description: Delete exactly DP_BASELINE_VERSION, DP_BASELINE_TAG, DP_BASELINE_COMMIT_SHA, DP_BASELINE_MANIFEST_URL, DP_BASELINE_MANIFEST_SHA256, DP_BASELINE_ARCHIVE_URL, DP_BASELINE_ARCHIVE_SHA256, DP_BASELINE_PROVENANCE, and DP_BASELINE_CLI_VERSION_RANGE. Retain inventory/provider/public-origin/database/publisher-token configuration. Do not deploy. Re-read stable and artifacts afterward.
• validation: The nine names are absent; deployment ID remains unchanged; stable and artifact responses remain identical and healthy.
• status: Completed
• log: Removed exactly the nine obsolete baseline identity environment names from the canonical production API project without deploying. A retry was a no-op. The environment retained the publisher token and public origin, stable authority remained on durable revision 2, and deployment identity remained dpl_CVSWHsq8bDiE7MCSv7tPE5JrCzRf.
• files edited/created: No repository implementation files; production environment configuration and IMPLEMENTATION-NOTES.md evidence only.
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [debugging-phase, security-best-practices]
• tdd_status: not_applicable
• tdd_target: not_applicable
• red_command: not_applicable
• expected_red_failure: not_applicable
• green_command: bun run --cwd apps/api validate:runtime-product -- --scenario baseline-ledger-cutover --phase remove-obsolete-env --apply
• reason_not_testable: This is an explicitly bounded production configuration cleanup after live no-redeploy proof, not code behavior.
• red_evidence:
• green_evidence: Redacted production environment-name readback showed all nine obsolete names absent while publisher token/public origin remained; repeated cleanup issued no removals; stable/artifact identity and deployment ID were unchanged.
• codebase_design_notes: Removes superseded deployment witnesses only after Postgres authority is proven; no broad environment cleanup is allowed.
• review_mode: cli
• runtime_validation: required
• runtime_target: Canonical Vercel API production environment and currently active deployment.
• runtime_evidence: Redacted env-name listing, unchanged deployment ID, and post-removal stable/artifact readbacks.
• runtime_cleanup: The deletion is intentional and persistent; do not remove any other variable and do not trigger a deployment.

T12: Document the new authority lifecycle and close delivery evidence

• depends_on: [T11]
• location: docs/README.md; docs/runbooks/hi-cli-scaffolding.md; apps/wiki/content/docs/project/runbooks/hi-cli-scaffolding.md; this plan and implementation notes
• description: Capture pre-edit diffs for the three dirty docs, then surgically replace nine-env/deploy guidance with publisher-token setup, ledger semantics, failure/reconciliation behavior, controlled rollback-as-append procedure, migration order, and proof expectations. Record exact test/runtime/review evidence while preserving unrelated existing hunks.
• validation: Operator docs contain one publication path, no baseline identity env/deploy instruction, explicit typed failure handling, secret redaction, rollback/audit guidance, and exact runtime proof.
• status: Completed
• log: Updated the repository and mirrored wiki runbooks plus docs/README.md to describe durable Postgres authority, append-only publish/rollback semantics, single-token publication, first-credential deployment, later no-redeploy publication/cleanup, no-clobber idempotency, and the CLI's 5-second remote authority timeout. Formatting, diff hygiene, and exact runbook mirror checks passed. The full wiki content check reached only pre-existing stale generated spec meta.json files outside this task.
• files edited/created: docs/README.md; docs/runbooks/hi-cli-scaffolding.md; apps/wiki/content/docs/project/runbooks/hi-cli-scaffolding.md; apps/wiki/content/docs/project/specs/cli/issue-94-durable-stable-baseline-promotion/PLAN.md; apps/wiki/content/docs/project/specs/cli/issue-94-durable-stable-baseline-promotion/IMPLEMENTATION-NOTES.md; apps/wiki/content/docs/project/specs/cli/issue-94-durable-stable-baseline-promotion/PHASE-HANDOFF.md; apps/wiki/content/docs/project/specs/cli/issue-94-durable-stable-baseline-promotion/meta.json.
• backlog_item_id: GH-94
• backlog_item_url: https://github.com/wearedevpunks/harness-intelligence/issues/94
• relation_mode: body-links
• assigned_skills: [docs-ingest-phase, logging-best-practices, simplify]
• tdd_status: not_applicable
• tdd_target: not_applicable
• red_command: not_applicable
• expected_red_failure: not_applicable
• green_command: rg -n "DP_BASELINE_PUBLISH_TOKEN|append-only|no redeploy|rollback|reconciliation" docs/README.md docs/runbooks/hi-cli-scaffolding.md apps/wiki/content/docs/project/runbooks/hi-cli-scaffolding.md && bun run --cwd apps/wiki check
• reason_not_testable: Documentation-only task validated by content search, wiki checks, and evidence review.
• red_evidence:
• green_evidence: oxfmt --check passed for all three docs, git diff --check passed, and the repository/wiki runbook bodies matched exactly. The wiki full check reported only pre-existing stale generated spec metadata, with no issue-94 runbook content mismatch.
• codebase_design_notes: Durable operational semantics remain in the repository runbook and private wiki; CLI README stays command-focused.
• review_mode: cli
• runtime_validation: not_required
• runtime_target: not_applicable
• runtime_evidence: not_applicable
• runtime_cleanup: not_applicable

Risks and Mitigations

Unresolved Questions

None. The user explicitly selected publisher-only machine authentication and excluded Backoffice.