docs(v0): dogfood actual flow vs operator mental model (Wizji-Wartości D2) #58

Merged

pdurlej merged 1 commit from claude/patchwarden-dogfood-actual-vs-mental-model into main

2026-05-27 15:59:51 +02:00

claude commented

2026-05-27 15:29:31 +02:00

Collaborator

What

Wizji-Wartości Wave step D2. New file docs/operations/dogfood-actual-vs-mental-model.md (+162 lines). Captures the gap between what cousins + operator assume the dogfood loop does on pdurlej/platform and what it actually does today.

Pure docs. 152/152 tests still green.

Why this file exists

On 2026-05-27, the operator described his expected dogfood pipeline as:

PR → deterministic Python/TS code check → linter → LLM cloud opinions → deterministic final checks → Iskra → merge.

Reading the actual .forgejo/workflows/patchwarden-client-dry-run.yml in pdurlej/platform showed only ~30% of that is wired today. Rest is either existing CLI capability not yet activated in the workflow, or genuinely not built (and parked under M2 per D21).

Without this file, a fresh cousin or operator could plausibly think "Patchwarden returned eligible_clean → diff is safe end-to-end" — exactly the failure mode that motivated the mental-model conversation. This file is the durable answer.

Structure

Section	Purpose
Operator mental model	The 6-step pipeline as the operator described it
Actual flow today	Narrative of what `dry-run` job really does (path classifier + stub review-run + empty resolver)
Step-by-step mapping	Per-step table: expectation vs reality vs why gap exists
Three luki end-to-end	Named + tracked: Luka 1+2 → platform#523 (codex); Luka 3 → parked under M2
What "dogfood ready" means today	Explicit operator framing: ✅ can honestly claim / ❌ cannot
What changes when #523 lands	Projected coverage ~30% → ~60% post-wiring
What needs to happen for 100%	Gap-closing list (NOT roadmap), M2-permitted vs parked

Three luki named

Luka 1: Ollama not wired in workflow. Capability in CLI since #49, not invoked by workflow. → tracked platform#523 (codex).
Luka 2: post-findings --execute not wired in workflow. Capability in CLI since #50, workflow only uploads artifacts. → same issue, bundled.
Luka 3: pyfallow/fallow-ts not wired into Patchwarden CLI. Runtime dep binding parked under M2. → plan doc D4 (pyfallow-integration-plan.md, next).

Honest framing — what can we claim today

✅ Path-prefix classification, stale branch / author-self-approval / required-check freshness, D20 sensor mode (build-time enforced since #55), fail-closed defaults in resolver (since #54).

❌ NO code-quality check (pyfallow not wired), NO content scanning (secrets-by-filename gap, documented in #56), NO real LLM opinion in workflow, NO PR comment from Patchwarden (until #523), NO automated Iskra handoff.

Per D21 — this is M2-permitted

Documentation of actual-vs-aspirational state is explicitly permitted under amended M2 (D21 §"Permitted"). This file does not propose new features, does not bind new runtime deps, does not change policy schema.

Atomic per ADR-0017

1 new file (docs/operations/dogfood-actual-vs-mental-model.md), +162 lines
Existing docs/operations/ directory (created PR #51)
0 src changes, 0 test changes
base=main post-D21 merge

Wizji-Wartości Wave status

PR	What	Status
D1 (#57)	D21 amendment	✅ merged
D2 (this PR)	dogfood actual-vs-mental-model	⏳ awaiting merge
D3	platform#523	🔵 codex working
D4	pyfallow-integration-plan.md	🟡 queued

Token-accounting

~3% weekly Opus. Synthesis from material I already had loaded (workflow source, decisions, code crosscheck snapshot).

## What **Wizji-Wartości Wave step D2.** New file `docs/operations/dogfood-actual-vs-mental-model.md` (+162 lines). Captures the gap between what cousins + operator assume the dogfood loop does on `pdurlej/platform` and what it actually does today. Pure docs. 152/152 tests still green. ## Why this file exists On 2026-05-27, the operator described his expected dogfood pipeline as: > *PR → deterministic Python/TS code check → linter → LLM cloud opinions → deterministic final checks → Iskra → merge.* Reading the actual `.forgejo/workflows/patchwarden-client-dry-run.yml` in `pdurlej/platform` showed only **~30%** of that is wired today. Rest is either existing CLI capability not yet activated in the workflow, or genuinely not built (and parked under M2 per D21). Without this file, a fresh cousin or operator could plausibly think *"Patchwarden returned `eligible_clean` → diff is safe end-to-end"* — exactly the failure mode that motivated the mental-model conversation. This file is the durable answer. ## Structure | Section | Purpose | |---|---| | Operator mental model | The 6-step pipeline as the operator described it | | Actual flow today | Narrative of what `dry-run` job really does (path classifier + stub review-run + empty resolver) | | Step-by-step mapping | Per-step table: expectation vs reality vs why gap exists | | Three luki end-to-end | Named + tracked: Luka 1+2 → platform#523 (codex); Luka 3 → parked under M2 | | What "dogfood ready" means today | Explicit operator framing: ✅ can honestly claim / ❌ cannot | | What changes when #523 lands | Projected coverage ~30% → ~60% post-wiring | | What needs to happen for 100% | Gap-closing list (NOT roadmap), M2-permitted vs parked | ## Three luki named 1. **Luka 1**: Ollama not wired in workflow. Capability in CLI since #49, not invoked by workflow. → tracked **platform#523** (codex). 2. **Luka 2**: `post-findings --execute` not wired in workflow. Capability in CLI since #50, workflow only uploads artifacts. → same issue, bundled. 3. **Luka 3**: pyfallow/fallow-ts not wired into Patchwarden CLI. Runtime dep binding parked under M2. → plan doc D4 (`pyfallow-integration-plan.md`, next). ## Honest framing — what can we claim today ✅ Path-prefix classification, stale branch / author-self-approval / required-check freshness, D20 sensor mode (build-time enforced since #55), fail-closed defaults in resolver (since #54). ❌ NO code-quality check (pyfallow not wired), NO content scanning (secrets-by-filename gap, documented in #56), NO real LLM opinion in workflow, NO PR comment from Patchwarden (until #523), NO automated Iskra handoff. ## Per D21 — this is M2-permitted Documentation of actual-vs-aspirational state is explicitly permitted under amended M2 (D21 §"Permitted"). This file does not propose new features, does not bind new runtime deps, does not change policy schema. ## Atomic per ADR-0017 - 1 new file (`docs/operations/dogfood-actual-vs-mental-model.md`), +162 lines - Existing `docs/operations/` directory (created PR #51) - 0 src changes, 0 test changes - `base=main` post-D21 merge ## Wizji-Wartości Wave status | PR | What | Status | |---|---|---| | D1 (#57) | D21 amendment | ✅ merged | | **D2 (this PR)** | dogfood actual-vs-mental-model | ⏳ awaiting merge | | D3 | platform#523 | 🔵 codex working | | D4 | pyfallow-integration-plan.md | 🟡 queued | ## Token-accounting ~3% weekly Opus. Synthesis from material I already had loaded (workflow source, decisions, code crosscheck snapshot).

claude added 1 commit

2026-05-27 15:29:31 +02:00

docs(v0): dogfood actual flow vs operator mental model 8234db90a5

Wizji-Wartości Wave step D2. Captures the gap between what cousins +
operator assume the dogfood loop does on pdurlej/platform and what it
actually does today (2026-05-27, post-D21 amendment, pre-#523 wiring).

## Why this file exists

On 2026-05-27 the operator described his expected pipeline:
PR → deterministic code-quality → linter → LLM cloud opinions →
deterministic final checks → Iskra → merge.

Reading the actual workflow (`.forgejo/workflows/patchwarden-client-dry-run.yml`
in pdurlej/platform) showed only ~30% of that is wired. The rest is
either existing CLI capability not wired into the workflow yet, or
genuinely not built (and parked under M2 per D21).

This file is the durable answer so the next cousin doesn't have to
repeat that conversation cold.

## Structure

- **Operator mental model** — the 6-step pipeline as described
- **Actual flow today** — narrative of what the workflow really does
- **Step-by-step mapping** — table per step: expectation vs reality vs
  why gap exists
- **Three luki end-to-end** — explicit names + tracking:
  - Luka 1: Ollama not wired in workflow → tracked in
    pdurlej/platform#523 (codex)
  - Luka 2: post-findings --execute not wired in workflow → same
    issue, bundled
  - Luka 3: pyfallow/fallow-ts not wired in Patchwarden CLI → parked
    under M2, plan in pyfallow-integration-plan.md (D4 next)
- **What "dogfood ready" means today** — explicit operator framing:
  what we can honestly claim ✅ and cannot ❌
- **What changes when #523 lands** — projected mental-model coverage
  ~30% → ~60%
- **What needs to happen for 100%** — gap-closing list, NOT a roadmap;
  M2-permitted vs parked categorization

## Why this matters

Prevents operator over-trust of `eligible_clean` verdicts. Without
this file, a cousin (or operator) could plausibly think "Patchwarden
returned eligible_clean → diff is safe end-to-end" — which is exactly
the failure mode that motivated the mental-model conversation today.

Pairs with `platform-dogfood.md` (what works) and
`code-vs-vision-snapshot-2026-05-27.md` (Bet 2 ratio analysis). This
file specifically focuses on the operator's mental-model gap.

## Test impact

None — docs-only. 152/152 tests still green.

## Atomic per ADR-0017

- 1 new file in existing `docs/operations/` directory (created PR #51).
- 0 src changes, 0 test changes.
- base=main (post-D21 merge).

## Wizji-Wartości Wave sequence

- D1 (#57): D21 amendment ✅ merged
- D2 (this PR): dogfood actual-vs-mental-model
- D3 (platform#523): workflow wiring → codex implementation
- D4 (next): pyfallow-integration-plan.md

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>