v0.23.0 — executor-service validator execution model

v0.23.0 — Executor-service validator execution model

Contents

Executor service — isolated validator execution behind a private HTTP API. The app container has zero Docker authority; the executor-service compose sibling owns the CT-local Docker socket and runs pinned validator images.

Backend-level reachability — pass-capability derivation keyed by backend_id (rev 3 amendment). The kind-level logic was unsafe once executor-service and docker-executor both map to container-runtime.

Receipt evidence binding — executor reports are verifiable evidence: executor_report_hash + executor_report_ref persisted durably; verifier resolves the ref, recomputes the hash, and compares before accepting pass. Persistence failure on a pass path downgrades to inconclusive.

Compose topology — gitwire-executor-service as a compose sibling with Docker socket mounted into executor only. App has no socket mount.

Validator image source — node:20-bookworm-slim with baseline repo at /opt/gitwire-base + deterministic workspace merge entrypoint.

Safety invariants

local-process never pass-capable
pass evidence requires live pass-capable backend + complete validator identity
executor reports are verifiable (ref resolves, hash recomputes)
uncaughtException → one shutdown attempt → process exits

Proof command set (v0.23.0)

• lint ✅
• test ✅
• build ✅
• typecheck ❌ (no root script — not supported in v0.23.0)

Known limitations

• Production CI-evidence envelope uses semantic IDs not in executor allowlist (Task 9 reconciles)
• DB-backed executor report recompute first exercised end-to-end in this release
• typecheck not supported
• Validator image must be built and pushed from the release commit

v0.22.0 — Gap 1 validator execution model + shutdown hardening

v0.22.0 — Gap 1 validator execution model + shutdown hardening

Contents

Gap 1 validator execution model (PR #18)

• Backend pass-capability derivation: local-process is never pass-capable; container-runtime is pass-capable only when reachable + backed by complete validator image identity; delegated-run has a vendor-neutral provider contract + null placeholder.
• /health extended with validator readiness: executor.selected_pass_capable, validator.configured, validator.pass_capable, validator.reason.
• Validator image identity resolution via GITWIRE_VALIDATOR_IMAGE_REF / GITWIRE_VALIDATOR_IMAGE_DIGEST (digest pinning + digest-match checks).
• Execution receipts extended with executor_kind, executor_pass_capable, validator_image_ref, validator_image_digest, validator_result, validator_result_status. proof_collected_at is a sibling (not in receipt_content) — preserves write-once dedup.
• Pure pass-gate helper validateGap1ValidatorBindings (checks 3f–3j).
• getDefaultBackend() reachability-honest for auto-selection (explicit configured selection unchanged).

Shutdown-handler crash-loop fix (PR #19, CT 115 incident 2026-06-21)

• Idempotent + bounded graceful shutdown. Fixes the crash-loop where an uncaughtException under memory pressure re-entered shutdown() and looped forever on db.end() "Called end on pool more than once".

Safety invariants

local-process never pass-capable
pass evidence requires live pass-capable backend + complete validator image identity
uncaughtException → ONE shutdown attempt → process exits

Version note

Package versions advance from 0.20.1 to 0.22.0. Intermediate tags v0.20.2, v0.20.3, and v0.21.0 shipped operational milestones without package-version bumps; v0.22.0 reconciles the package version with the current release line.

Exclusions

• No database migration.
• No CT 115 ad-hoc changes outside the deployment runbook.

v0.21.0 — Deployment Discipline, Governance Hardening, Executor Reachability

v0.21.0 closes the CT 115 resilience arc: fail-closed migrations, durable Redis policy, build identity, governance guards, and executor reachability are now externally observable through health/readiness and CI.

Highlights

v0.20.1-A — Deployment Discipline

• Fail-closed migration entrypoint (docker-entrypoint.sh)
• Durable Redis memory ceiling in Docker Compose (256mb, noeviction, appendonly)
• /health deployment visibility (version, git SHA, applied/available migrations)
• CI Docker build + smoke gate (app + dashboard images)
• Fresh-DB migration 019 fix (repo_full_name column gap caught by CI)
• Runbook reconciliation updates

v0.20.2 — Version Centralization

• Committed build-info fallback module (core + dashboard)
• Build-time metadata generation (scripts/generate-build-info.js)
• GITWIRE_COMMIT_SHA Docker/compose wiring
• Dashboard footer reads build-info instead of hardcoded v0.12.0
• Version drift CI test (scripts/check-version-drift.js)
• Version policy documentation

v0.20.3 — Governance Hardening

• Execute-time drift re-check (checkDrift before mutation)
• Typed blocked reasons (BLOCKED_REASONS enum, 11 values)
• blocked as first-class terminal state (distinct from failed)
• Marker-backed comments ( pattern)
• Abstention metrics API (GET /api/actions/abstentions)
• Migration 037: blocked_reason column

v0.21.0 — Executor Reachability

• EXECUTOR_KINDS taxonomy (local-process / container-runtime / delegated-run)
• Reachability probes (Docker/Podman, local, delegated placeholder)
• Backend selection policy with priority ordering
• /health executor summary (externally observable topology)
• Docker-unavailable produces typed reason, not ambiguous failure

Production verification

{
  "status": "ok",
  "version": "0.20.1",
  "git_sha": "172fc5c8e538",
  "db_migrations_applied": 37,
  "db_migrations_available": 37,
  "db_migration_status": "current",
  "executor": {
    "selected_kind": "local-process",
    "selected_reason": "selected:local-process"
  }
}

What this prevents

• Migration drift (entrypoint auto-applies on every start)
• Redis unbounded growth (durable compose command)
• Unbuildable code merging (CI smoke gate)
• Version drift across surfaces (drift CI test)
• Stale execution (drift re-check + typed blocked reasons)
• Comment spam (marker-backed comments)
• Silent abstention (typed reasons + abstention metrics API)
• Ambiguous executor failure (reachability layer)

v0.20.1 — Deployment Discipline

v0.20.1 hardens GitWire deployment after the CT 115 production reconciliation.

Highlights

• Fail-closed migration entrypoint — the app container now runs node scripts/migrate.js before startup and exits non-zero on migration failure, preventing workers from running against an uncertain schema.
• Durable Redis memory ceiling — maxmemory 256mb + noeviction are now baked into the Docker Compose command:, surviving container recreation (previously CONFIG SET was process-memory only and reset to 0 on any recreate).
• /health deployment visibility — now reports version, git_sha, db_migrations_applied, db_migrations_available, and db_migration_status (derived from applied-vs-available, not a hardcoded target). status degrades to "degraded" when migrations are behind or unknown.
• CI Docker build + smoke gate — every PR now builds and boots both the app and dashboard production images against ephemeral service containers, catching the "merged but never rebuilt" failure class.
• Fresh-DB migration 019 fix — the new CI smoke gate caught a latent schema gap: migration 019 indexed managed_actions(repo_full_name) but no migration ever added that column. Invisible on CT 115 (warm DB) but fatal on a fresh DB.
• Deployment runbook updated — canonical migration runner, Redis persistence behavior (CONFIG SET ephemerality, compose durability), CRLF normalization for emergency scp hotfixes, fail-closed entrypoint behavior, and drift verification via /health.

Production verification

• CT 115 rebuilt from master successfully.
• /health reports status=ok and db_migration_status=current (36/36).
• Redis maxmemory persists across rebuild at 268435456 with noeviction and appendonly=yes.
• All containers healthy and logs clean.

What this prevents

The drift class discovered during the CT 115 reconciliation: future rebuilds can no longer silently run stale code, stale schema, or unbounded Redis. Deployment state is now externally observable via /health, and unbuildable code is caught at PR time rather than during an emergency deploy.

Deferred

Version centralization (single build-info source of truth, GITWIRE_COMMIT_SHA wiring, dashboard footer) remains planned for v0.20.2. The git_sha field in /health is currently null until that wiring lands.

v0.20.0 — Isolated Pass-Capable Executor

v0.20.0 — Isolated Pass-Capable Executor

This is the milestone release. verified and review_ready are now legitimately reachable under a strict proof chain.

What this release delivers

For the first time, the full repair pipeline is operationally pass-capable:

detected → evidence_collected → proposed → verified → review_ready → approved → applied

A pass receipt is accepted only when:

1. The backend is explicitly pass-authorized (docker-executor only)
2. Valid durable backend isolation evidence exists for that backend and image digest
3. The receipt binds to the exact same image identity and locked proposal inputs
4. Every validation command completed successfully under the verified isolated backend

PRs Shipped

#	Title	Commit
54	Executor backend abstraction + Docker/Podman implementation	0226a8b
55	E2E isolation evidence + immutable OCI image identity	f689f88
56	Pass-capable unlock: backend evidence gate, docker-executor enabled	5411c67

New Infrastructure

• ExecutorBackend abstraction: Contract-based backend selection with describe() / run()
• docker-executor: Full container isolation (--network=none, --read-only, --user, --cpus, --memory, --pids-limit)
• node-executor: Host spawn (always inconclusive, not pass-capable)
• Image identity: GITWIRE_VALIDATOR_IMAGE_REF config, parseImageReference(), isDigestPinned()
• Runtime inspection: inspectContainerImage(), verifyImageIdentity(), computeInspectionHash()
• Isolation probes: 10 required probes (network, credentials, non-root, read-only, limits, socket)
• Backend evidence store: Durable, audit-complete, content-addressed
• Migration 036: backend_isolation_evidence table with inspection columns
• Verifier check 3e: Backend evidence gate wired into lifecycle verifier

Test Coverage

60 suites, 2,196 tests — all green.

Production Deployment

Before pass-capable execution works in production:

1. Build a real validator image and set GITWIRE_VALIDATOR_IMAGE_REF
2. Run isolation probes and store backend evidence
3. Configure Docker/Podman with the required isolation flags

Non-blocking follow-up

Make runtime_version binding symmetric between receipt and evidence (currently checked only when both sides present).

v0.19.0 — Verified Repair Proposal Governance Scaffolding

v0.19.0 — Verified Repair Proposal Governance Scaffolding

v0.19.0 implements the governed repair-proposal lifecycle, durable evidence boundaries, patch artifacts, verification-result gates, critic-review gates, and receipt/snapshot scaffolding.

Passing verification remains disabled until an isolated executor backend is authorized. verified and review_ready are intentionally unreachable — ALLOWED_PASS_EXECUTION_BACKENDS is empty and the host spawn executor always returns inconclusive.

Repair Pipeline

detected → evidence_collected → proposed → verified → review_ready → approved → applied → verified_after_apply

States verified and review_ready are structurally wired but dormant.

Items Shipped

#	Item	PR	Commit
1	Repair Proposal Model	#47	dd0923c
2	Trusted CI Evidence Collection	#48	8eb9aea
3	Diagnosis Worker	#49	3ee70cf
4	Patch Proposal Worker	#50	b744638
5	Verification Boundary	#51	6a45db9
6	Critic Review Boundary	#52	fc81bda
7	Execution-Receipt Backend	#53	ebcff5d

New Infrastructure

• Migrations: 031–035 (repair proposals, event provenance, patch artifacts, execution receipts, source snapshots)
• Canonical methods: recordCiEvidenceCollection(), recordPatchProposal(), recordVerificationResult(), recordCriticReview()
• Shared verifier: 15-check verifyExecutionReceiptAgainstLockedProposal() — used by both verification and critic gates
• Durable receipts: Content-addressed, write-once, re-hashed under lock
• Source snapshots: Composite key (snapshot_hash, repo_full_name, base_sha) prevents cross-repo collisions
• Background queues: ci-evidence, diagnosis, patch, verification, critic

Test Coverage

57 suites, 1,961 tests — all green.

Next Milestone

v0.20.0 — Isolated Pass-Capable Executor: A Docker/Podman/nsjail backend can produce a pass receipt only when it runs the canonical validation plan in an isolated, resource-bounded environment with no network, no credentials, non-root execution, pinned image digest, and verified source/artifact bindings.

v0.18.0 — Operator Onboarding

What's New

GitWire now guides new operators from first dashboard login to a safe governed rollout: verify setup, choose an appropriately safe starter policy, validate and simulate it, then promote it through the governed rollout lifecycle.

First-Run Setup Checklist

The dashboard shows an 8-check panel that surfaces installation state immediately:

Check	Blocking	What it verifies
GitHub App configured	✅	App ID and private key are set
Database connected	✅	PostgreSQL is reachable
Redis connected	✅	Redis is reachable
GitHub App installed	✅	At least one installation is linked
Repositories synced	✅	At least one repo has been imported
Webhook events received	⚠️ (warn)	Webhooks flowing within 7 days
Policy file configured	⚠️ (warn)	.gitwire.yml or dashboard overrides exist
Dry-run mode	ℹ️ (info)	Shows whether dry-run is active

The checklist auto-hides when ready and provides a "next step" CTA. No secret values are ever returned.

Safe Starter Policy Templates

When .gitwire.yml is missing, the checklist shows 5 templates with explicit safety labels:

Template	Safety Label	Best For
Starter (Dry-Run)	🟢 Dry-run protected	Safest first config — all pillars observe only
Triage Only	🟢 Low-risk live	Issue/PR labeling — labels and comments only
CI Healing (Preview)	🔵 Safe to preview	CI diagnosis without patching
Open-Source Maintainer	🟡 Review before rollout	Balanced automation for public repos
Strict Governance	🟢 Dry-run protected	Enterprise/regulated repos — audit-first

10-Step Onboarding Walkthrough

A complete guide takes operators from zero to first governed rollout: First-Run Onboarding

graph LR
    A[Install] --> B[Configure App]
    B --> C[Start Services]
    C --> D[Open Dashboard]
    D --> E[Use Checklist]
    E --> F[Pick Template]
    F --> G[Validate]
    G --> H[Simulate]
    H --> I[Create Rollout]
    I --> J[Approve & Promote]

Security

• Path injection fix in template service (CodeQL-identified, defense in depth)
• CodeQL workflow_dispatch added for manual baseline refresh
• Tracking issue #46 for 12 pre-existing CodeQL alerts

Landing & Docs Refresh

• Updated test count, features, and GitHub links across landing page
• README: new Operator Onboarding section with API endpoints
• Docs index reordered to product story order

New API Endpoints

Endpoint	Purpose
GET /api/setup	8-check setup status with overall state and next step
GET /api/setup/templates	List all starter policy templates
GET /api/setup/templates/:id	Get a template with full YAML content

Full Changelog: v0.17.0...v0.18.0

v0.17.0 — Policy Rollout Controls

GitWire v0.17.0 turns policy preview into a controlled rollout workflow with approval, promotion, and rollback evidence.

This release adds a governed lifecycle for moving policy from proposed → dry-run → live → rolled back, with full audit trail.

Highlights

• Policy rollout plan model (8-state lifecycle)
• Rollout approval workflow (evidence + critical recommendation acknowledgement required)
• Dry-run-to-live promotion (the only path that writes policy)
• Rollback evidence (config hashes, replaced-config snapshot)
• Rollout dashboard (/rollouts) with lifecycle timeline and state-driven actions
• Non-mutating safety model preserved for preview/simulation

Why it matters

v0.16.0 answered: "What would this policy do?"

v0.17.0 answers: "How do I safely move this policy from proposed → dry-run → live → monitored, with approval and rollback?"

Operators can now:

• Create a rollout plan with proposed policy
• Attach validation, simulation, diff, and recommendations evidence
• Request review and get explicit approval (with critical risk acknowledgement)
• Promote the approved policy to live (with previous policy snapshot for rollback)
• Roll back safely if needed (with full audit evidence)

Safety guarantees

• Promotion is the only path that writes policy — generic transitions blocked
• Write-before-transition — if policy write fails, state does not change
• Previous policy snapshot captured before every promotion
• Rollback evidence includes config hashes for audit proof
• Approval requires critical recommendation acknowledgement
• All 4 evidence types required before approval

Included PRs

• #39 — Policy rollout plan model
• #40 — Rollout approval workflow
• #41 — Dry-run-to-live promotion
• #42 — Rollback evidence
• #43 — Rollout dashboard
• #44 — Documentation + release

New API endpoints

Endpoint	Purpose
POST /api/rollouts	Create rollout plan
GET /api/rollouts	List plans with filters
GET /api/rollouts/:id	Get plan detail
PATCH /api/rollouts/:id/evidence	Attach evidence
POST /api/rollouts/:id/approve	Approve plan
POST /api/rollouts/:id/reject	Reject plan
POST /api/rollouts/:id/promote	Promote to live policy
POST /api/rollouts/:id/rollback	Roll back to previous policy

Test status

• 42 suites
• 1104 tests
• CI green: syntax-check, rules-tests, web-tests
• CodeQL green
• Protected-branch flow with admin enforcement
• Deploy workflow passing on self-hosted runner

Release line

v0.14.0-public-baseline → v0.14.1 → v0.15.0 → v0.16.0 → v0.17.0

v0.16.0 — Policy Preview & Simulation

GitWire v0.16.0 helps operators understand policy changes before automation acts.

This release adds a non-mutating policy preview workflow for validating .gitwire.yml, simulating proposed policy against historical decisions, comparing current vs proposed behavior, and generating deterministic guardrail recommendations.

Highlights

• Policy validation API
• Policy preview dashboard
• Historical event simulation
• Policy diff impact view
• Guardrail recommendations
• Non-mutating safety model: no config saves, no queue jobs, no GitHub writes

Why it matters

GitWire's operating model is Decide. Execute. Prove.

v0.16.0 adds a new preflight layer before execution:

Validate policy. Preview behavior. Simulate impact. Review guardrails. Then roll out safely.

Operators can now answer:

• Is this .gitwire.yml valid?
• Which pillars does it enable?
• Is dry-run protecting this rollout?
• Which settings are risky?
• How would this policy behave against recent repository history?
• What changes compared to the current repo policy?
• Would this policy act on more events?
• What guardrails should be added before rollout?

Included PRs

• #32 — Policy validation API
• #33 — Policy preview dashboard
• #34 — Historical event simulation
• #35 — Policy diff impact view
• #36 — Guardrail recommendations
• #37 — Documentation + release

New API endpoints

Endpoint	Purpose
POST /api/config/validate	Validate policy YAML, return errors/warnings/risks
POST /api/config/simulate	Replay proposed policy against historical events
POST /api/config/diff-impact	Compare current vs proposed policy behavior
POST /api/config/recommendations	Generate deterministic guardrail recommendations

Test status

• 36 suites
• 766 tests
• CI green: syntax-check, rules-tests, web-tests
• CodeQL green
• Protected-branch flow with admin enforcement
• Deploy workflow passing on self-hosted runner

Release line

v0.14.0-public-baseline → v0.14.1 → v0.15.0 → v0.16.0

v0.15.0 — Operator Trust & Observability

GitWire v0.15.0 turns the "Prove" side of GitWire into a first-class operator experience.

This release adds dashboard and API surfaces for inspecting, filtering, explaining, and exporting GitWire automation evidence.

Highlights

• Managed action lifecycle view — inspect the lifecycle of proposed, approved, executed, succeeded, failed, and reconciled actions
• Decision log search and filters — search and filter by repository, pillar, source, target, outcome, trigger event, and time range
• Waiver visibility — review active, expiring, and expired policy waivers, including who granted them and why
• Dry-run proof view — see what GitWire would have done without mutating GitHub, with safety-first labeling
• Exportable audit bundles — export bounded JSON or Markdown evidence packages with recursive secret redaction

Why it matters

GitWire is not just an AI automation bot for GitHub. It is a governance layer for repository automation.

v0.15.0 helps operators answer:

• What did GitWire decide?
• What did it execute?
• What did it skip?
• What would it have done in dry-run?
• Which waivers affected automation?
• What evidence supports the action?
• What proof can be exported for review or audit?

Included PRs

• #25 — Managed action lifecycle view
• #26 — Decision log search/filter
• #27 — Waiver visibility
• #28 — Dry-run proof view
• #29 — Exportable audit bundle
• #30 — Documentation and version bump

Test status

• 30 suites
• 484 tests
• CI green: syntax-check, rules-tests, web-tests
• CodeQL green
• Protected-branch flow enforced (admin enforcement enabled)
• Deploy workflow passing on self-hosted runner

Release line

v0.14.0-public-baseline → v0.14.1 → v0.15.0

---

Full Changelog: v0.14.1...v0.15.0