dotfiles/claude/memory/feedback-action-completes-outcome-integration-completes-work.md

name, description, type, originSessionId

name	description	type	originSessionId
Action completes the outcome — integration completes the work	Umbrella drift pattern across multiple layers (substrate, build, editorial, memory). The visible outcome appears complete; the integration step that makes the artifact durable/findable/correct is silently skipped. Surfaces as deploy ≠ commit, write ≠ index, draft ≠ verify, count ≠ vault-write. Saved 2026-05-06 after three same-shape instances in a single session.	feedback	3bf7ae75-1138-4745-9024-0c40b3755ad3

Pattern: A structural action produces a visible outcome that looks complete. The action's integration step — the move that ties the outcome into a durable, findable, or verified state — is silently skipped. The work appears done; the work is not done. The drift is invisible until a downstream check (next session, next collaborator, next verification) surfaces the gap.

Instances of the same shape

This is an umbrella feedback covering recurring instances across multiple layers.

Substrate layer — count ≠ vault-write (named 2026-05-05 as structural-counter-as-health-signal):

• MemPalace's drawer counter said "succeeded" but vault writes were silently dropped.
• The counter (visible outcome) reported integrity that the vault (durable substrate) didn't hold.

Build/deploy layer — deploy success ≠ deployed correctness (named 2026-05-05):

• CloudFlare reported "deploy success" but stale CSS shipped because Hakyll didn't track SCSS partials.
• The deploy result (visible outcome) reported integrity that the compiled artifact (correct CSS) didn't hold.

Editorial-process layer — deploy ≠ commit (named 2026-05-06):

• After the Reply Sources fix was deployed via make build and visually verified, but git commit was never run.
• The visual verification (visible outcome) reported integrity that the repo state (durable artifact) didn't hold.

Memory layer — write ≠ index (named 2026-05-06):

• Project memory file was created but never indexed in MEMORY.md, making it invisible to /wake-up and to other sessions.
• The file existed (visible outcome) but was unfindable downstream until the index entry was added.

Code-edit layer — draft ≠ verify (recurring throughout):

• SCSS edit compiled with no error, but a Sass shorthand expression was parsed as subtraction and produced wrong output.
• The build success (visible outcome) reported integrity that the compiled CSS (correct rules) didn't hold.

Why this is one pattern, not five

Each instance has the same architecture:

1. Visible outcome layer — the green light, the success message, the file created, the deploy completed
2. Integration step — the move that ties the visible outcome into the layer where it becomes load-bearing for downstream work
3. Missing-integration drift — the visible outcome is treated as complete; downstream work proceeds on the assumption of complete integration; the gap surfaces only when something breaks or someone checks

The contamination architecture: the system is trained to terminate on visible success. The visible outcome looks complete because that is what is rewarded; the integration step is not rewarded because it is invisible until a future failure. So the executor terminates on outcome, not on integration. This is the same shape as the original contamination problem — outputs that satisfy the interlocutor rather than outputs that are true — applied at the structural-action layer rather than the prose layer.

How to apply

The general rule: every structural action has an integration step. The work is not done until the integration step is done.

Concrete pairings to maintain across ARC editorial work (extend as new layers surface):

Visible outcome	Integration step	The check that catches the gap
Edit a file	git status + git commit	Working tree clean at session end
Deploy a page	git status + git commit + git push	Repo state matches deployment
Write a memory file	Add index entry to MEMORY.md	File findable via /wake-up
Compile SCSS	Inspect compiled CSS for the specific rule changed	Output matches authorial intent
Update spec	Update implementation to match (or note the gap)	Spec/code drift tracked or closed
Resolve a question	Save the resolution as memory if it will recur	Future session inherits the answer
Build clean	Visually verify on representative page	"Built" is not "looks right"
Run a counter (in any system)	Verify the counted thing actually persists	Don't trust counters as integrity-claims

At session end: walk the layers. For each substantive action this session, was the integration step done? git status is the gating check at the editorial layer; MEMORY.md is the gating check at the memory layer; visual verification is the gating check at the implementation layer.

At session start: trust nothing about structural state without checking. Yesterday's "deployed and verified" doesn't mean today inherits a clean repo. Yesterday's "memory written" doesn't mean today's wake-up sees it. Verify, then proceed.

Cross-reference

• feedback-deploy-is-not-commit.md — the editorial-layer instance (2026-05-06)
• 2026-05-05 session memory — substrate-counter and build-pipeline instances
• The original contamination problem (~/_Dev/CapableMind-AI/docs/thinking/David/methodology/contamination-problem.md) — the source architecture this pattern instantiates at the structural-action layer

Why the umbrella is worth keeping rather than only the per-layer instances

The per-layer instances are useful for specific recall (when next at the deploy step, recall deploy ≠ commit). The umbrella is useful for new layers as they emerge — when a new instance surfaces (a new "X ≠ Y" pair), the umbrella says: this is the same pattern, apply the same discipline (integration step is part of the work, not after it).

Steward authorization to save: "yes" (2026-05-06, after I named three same-shape instances and asked whether they warranted one umbrella entry rather than three siblings).