go-go-golems/docmgr/diary

docmgr doc add \
  --ticket TICKET-ID \
  --doc-type reference \
  --title "Diary"

docmgr doc relate \
  --doc ttmp/.../reference/01-diary.md \
  --file-note "/abs/path/to/file.go:Why this file matters"

docmgr changelog update --ticket TICKET-ID \
  --entry "Step N: ... (commit <hash>)" \
  --file-note "/abs/path/to/file.go:Reason"

# 1) Implement + format + test (capture failures verbatim)
gofmt -w path/to/file.go && go test ./... -count=1
 
# 2) Commit code (focused)
git add path/to/file.go && git commit -m "..." && git rev-parse HEAD
 
# 3) Update ticket bookkeeping (use the stable task ID from 'docmgr task list',
#    e.g. [v0sv]; 1-based positions also work)
docmgr task check --ticket TICKET-ID --id v0sv
 
# 4) Update diary + relate files + update changelog (include commit hash)
docmgr doc relate --doc ttmp/.../reference/01-diary.md \
  --file-note "/abs/path/to/file.go:What changed (commit <hash>)"
docmgr changelog update --ticket TICKET-ID \
  --entry "Step N: ... (commit <hash>)" \
  --file-note "/abs/path/to/file.go:Reason"
 
# 5) Commit docs changes
git add ttmp/... && git commit -m "Diary: record Step N"

# Diary
 
## Goal
 
Brief statement of what this diary captures.
 
## Step N: [Descriptive Step Name]
 
Write 1–2 short prose paragraphs here (required). Explain intent, what changed at a high level, and what it unlocked.
 
### Prompt Context
 
**User prompt (verbatim):** "<paste exactly what the user typed>"
 
**Assistant interpretation:** <your interpretation of what the user is asking for (paraphrase)>
 
**Inferred user intent:** <what outcome the user is trying to achieve / why they asked>
 
**Commit (code):** <hash> — "<message>"   # if code changed
 
### What I did
-Concrete actions (files changed, commands run)
 
### Why
-Motivation / rationale
 
### What worked
-Outcomes that moved the work forward
 
### What didn't work
-Failures/blockers with exact errors, versions, and commands
 
### What I learned
-Insights, corrected assumptions, patterns
 
### What was tricky to build
-Sharp edges: invariants, ordering constraints, normalization quirks, deadlocks, etc.
 
### What warrants a second pair of eyes
-Review-critical correctness/perf/concurrency risks
 
### What should be done in the future
-Only follow-ups implied by this step; if nothing: `N/A`
 
### Code review instructions
-Where to start (files + key symbols)
-How to validate (commands/tests)
 
### Technical details
-Reference material (snippets, schema/contracts, command examples)