draft-punks/PRODUCTION_LOG.mg at main · flyingrobots/draft-punks · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
# Draft Punks — Production Log

Guideline: Append an entry for any unexpected/unanticipated work, dependency, requirement, or risk we discover during implementation and testing.

Template

````markdown
## Incident: <title>

Timestamp: <YYYY-MM-DD HH:MM:SS local>

Task: <current task id>

### Problem

<problem description>

### Resolution

<resolution>

### What could we have done differently

<how could this have been anticipated? how should we have planned for this? what can we do better next time to avoid this sort of issue again?>
````

## Incident: Product Pivot to CLI-Only (Git-backed State)

Timestamp: 2025-11-07 19:07:32

Task: DP-F-20 / Sprint 0 planning

### Problem
TUI cannot be driven programmatically in our harness and is slower to iterate for both humans and LLMs.

### Resolution
Pivot to a CLI-only experience with a Git-backed state repo and JSONL stdio server. Update SPRINTS.md, add CLI-STATE.md, and refocus FEATURES/TASKLIST over time.

### What could we have done differently
Call out environment constraints earlier and consider dual-mode from day one. Favor CLI-first for automation-heavy tools; treat TUI as an optional skin over the same state engine.

## Incident: Local test runner missing (pytest not installed)

Timestamp: 2025-11-08 ~00:00:00 (estimated; exact time not recorded)

Task: DP-F-30 / Thread verbs + Debug LLM (tests-first)

### Problem
The environment lacks `pytest`, so tests could not be executed immediately after adding failing tests.

### Resolution
Committed failing tests first, then implemented the features. Left tests in place for local/CI execution. Next dev step is `make dev-venv && . .venv/bin/activate && pip install -e .[dev] && pytest`.

### What could we have done differently
Include a lightweight script or Makefile target that ensures a dev venv with pytest is provisioned before test steps, or run tests inside CI where the toolchain is guaranteed.

## Incident: Doghouse Reboot (The Great Pivot)

Timestamp: 2026-03-27 14:00:00 (estimated)

Task: DP-F-21 / Doghouse flight recorder reboot

### Problem
Project had drifted into "GATOS" and "git-mind" concepts that strayed from the original PhiedBach vision and immediate needs.

### Resolution
Rebooted the project to focus on **DOGHOUSE**, the PR flight recorder. Deleted legacy TUI/kernel, implemented hexagonal core, and restored the original lore.

### What could we have done differently
Established clearer scope boundaries earlier. The pivot from TUI to CLI to git-mind to Doghouse reflects successive scope corrections that could have been one decision with a tighter product brief upfront.

## Incident: Doghouse Refinement (Ze Radar)

Timestamp: 2026-03-28 15:00:00 (estimated)

Task: DP-F-21 / Refinement & CodeRabbit feedback

### Problem
The initial Doghouse cut lacked live monitoring, repro capabilities, and sensitivity to merge conflicts vs. secondary check failures.

### Resolution
Implemented `doghouse watch`, `doghouse export`, and the Blocking Matrix. Hardened adapters with timeouts and deduplication. Addressed 54 threads of feedback.

### What could we have done differently
Include watch/export in the initial cut. The design brief (flight-recorder-brief.md) already described these use cases but they were deferred to a second pass, creating churn when the first review surfaced them as gaps.