---
name: Deploy is not commit — visual verification masks missing durable artifact
description: A drift pattern where shipping a visible result (deployed page, build
  success) is treated as task completion, while the durable artifact (git commit +
  push) is silently skipped. Caught 2026-05-06 in the After the Reply Sources fix.
type: feedback
originSessionId: 3bf7ae75-1138-4745-9024-0c40b3755ad3
permalink: claude-memory/feedback-deploy-is-not-commit
---

**Pattern:** I edit a file, run `make build` which deploys, the steward verifies visually, work appears complete — but `git commit` was never run. The repo and the deployment desynchronize. The next session inherits an inconsistent tree.

**Caught 2026-05-06**: After the Reply sequence-index Sources fix (three-em rule) was deployed via `make build` and visually verified by the steward. The commit step was skipped. Discovered at session-end via `git status` showing the file as modified (not committed). Committed retroactively as 3d96449.

**Why this matters (drift architecture):** This is the *structural-counter-as-health-signal* pattern from 2026-05-05, applied at the editorial-process layer rather than at the substrate layer:

- **Yesterday (mempalace):** the drawer counter said "succeeded" but vault writes were silently dropped → false reassurance about substrate integrity.
- **Yesterday (build pipeline):** the CloudFlare deploy reported "success" but stale CSS shipped because Hakyll didn't track SCSS partials → false reassurance about deploy integrity.
- **Today (deploy ≠ commit):** the visual verification said "looks good" but the repo state lagged the deployment → false reassurance about repo integrity.

The shape is identical: a visible/structural success-signal is treated as evidence of full integrity, but the actual integrity check (vault freshness, compiled CSS mtime, git status) tells a different story. Each instance is a contamination-aware drift: the work *looks* complete, the deeper substrate is not.

**How to apply:**
- At every "task complete" moment in ARC editorial work, run `git status` before declaring done. If the working tree shows uncommitted modifications to files that were the object of the task, the task is not yet complete.
- Match the *shape* of the artifact to the *shape* of the integrity claim. "Deployed and verified" claims integrity at the visual layer. "Repo state matches the deployed state" is a separate claim at a separate layer.
- The discipline is the same as in code: `compile` is not the same as `pass tests` is not the same as `merge`. In ARC: `edit` is not `build` is not `deploy` is not `commit` is not `push`. Each step is its own integrity gate.
- For session-end discipline: include `git status --short` and `git log --oneline -3` as part of the wrap-up check. If `status` shows uncommitted ARC content/spec/scss changes from the day, commit them or surface why they're held.
- For mid-session discipline: after each substantive edit + verify cycle, commit before moving to the next task. The act of committing forces a brief audit ("what am I committing?" "what's the message?") that is itself a useful integrity check.

**Cross-reference:**
- 2026-05-05 session: structural-counter-as-health-signal pattern named at the substrate + build-pipeline layers
- Today's contamination-awareness: this is the editorial-process layer instance of the same pattern
- ARC CLAUDE.md prime directive: *"things done once, correctly, with lasting integrity"* — the integrity layer that was missing here was the repo, not the deploy

**Steward authorization to save:** *"please note it."* (2026-05-06, after I surfaced the catch)