* test(#4384): failing-first regression rows for the macOS long-base todo-cap failure The 240-char pending-todo bullet cap must be deterministic w.r.t. where the repo is checked out. Deterministic long-base-path fixtures (a single 110-char segment, no real macOS dependency) reproduce next's own macos shard 3/3 failure (run 34038716700) on every OS: with an absolute link the bullet exceeds the cap and the documented needs-first truncation drops the 'Needs <solution>' clause. Rows cover the determinism property (byte-identical bullets under short and long bases), the CLI surface, relative-path stability, legacy no-projectRoot behavior, drop-order preservation, and adversarial edges (outside-root, path===root, non-string path). * fix(#4384): render the pending-todo bullet link repo-relative renderPendingTodosMarkdown gains an optional projectRoot; when given and the todo's path is absolute, the bullet's [todo file](…) target becomes toPosixPath(path.relative(projectRoot, path)) — the idiom already used for project_exists. cmdInitTodos passes cwd. The JSON todos[].path field stays absolute (#2376). Only the rendered display link changes: embedding the machine-variable absolute base let macOS's /private/var/folders/… temp paths consume the 240-char budget and drop the 'Needs' clause on long-path machines only — next's own macos-latest shard 3/3 went red on exactly this (run 34038716700), Linux's short /tmp passed. The 240-char whole-bullet cap and the needs→title→area drop order are unchanged; this matches PR #4384's own canonical example, docs, and unit tests, which all show repo-relative links. Docs updated at all three surfaces that describe the bullet (COMMANDS.md, templates/state.md, reference/state-md.md — the last was still pre-#4384 'count and reference' prose). Fixes the macOS regression introduced by #4384; next is red on its own CI. * test(#4384): fix substring false positive in the outside-root regression row The ../-form relative link legitimately contains the absolute path as a substring, so !line.includes(absolutePath) fired on correct output (caught by the first remote verify run, linux-node24 44018/44019). Assert the property itself instead: extract the link target and require it to be non-absolute and not equal to the absolute path. * chore(#4398): backfill PR number in changeset --------- Co-authored-by: sim <sim@local>
5.6 KiB
State Template
Template for .planning/STATE.md — the project's living memory.
File Template
The frontmatter block below is generated from STATE_FIELD_SCHEMA
(src/state-md-schema.cts, ADR-3473 §8.8) by scripts/gen-state-md-docs.cjs --write — do not hand-edit the marked region; the body below it is
hand-authored.
---
gsd_state_version: '1.0' # placeholder; syncStateFrontmatter overwrites on first state.* call
status: planning
progress:
total_phases: 0
completed_phases: 0
total_plans: 0
completed_plans: 0
percent: 0
---
<!-- STATE-MD-SCHEMA:END:frontmatter -->
# Project State
## Project Reference
See: .planning/PROJECT.md (updated [date])
**Core value:** [One-liner from PROJECT.md Core Value section]
**Current focus:** [Current phase name]
## Current Position
Phase: [X] of [Y] ([Phase name])
Plan: [A] of [B] in current phase
Status: [Ready to plan / Planning / Ready to execute / In progress / Phase complete]
Last activity: [YYYY-MM-DD] — [What happened]
Progress: [░░░░░░░░░░] 0%
## Performance Metrics
**Velocity:**
- Total plans completed: [N]
- Average duration: [X] min
- Total execution time: [X.X] hours
**By Phase:**
| Phase | Plans | Total | Avg/Plan |
|-------|-------|-------|----------|
| - | - | - | - |
**Recent Trend:**
- Last 5 plans: [durations]
- Trend: [Improving / Stable / Degrading]
*Updated after each plan completion*
## Accumulated Context
### Decisions
Decisions are logged in PROJECT.md Key Decisions table.
Recent decisions affecting current work:
- [Phase X]: [Decision summary]
- [Phase Y]: [Decision summary]
### Pending Todos
[From .planning/todos/pending/ — ideas captured during sessions]
None yet.
### Blockers/Concerns
[Issues that affect future work]
None yet.
## Deferred Items
Items acknowledged and deferred at milestone close, most recent first:
| Category | Item | Status | Deferred At | Milestone |
|----------|------|--------|-------------|-----------|
| *(none)* | | | | |
## Session Continuity
Last session: [YYYY-MM-DD HH:MM]
Stopped at: [Description of last completed action]
Resume file: [Path to .continue-here*.md if exists, otherwise "None"]
STATE.md is the project's short-term memory spanning all phases and sessions.
Problem it solves: Information is captured in summaries, issues, and decisions but not systematically consumed. Sessions start without context.
Solution: A single, small file that's:
- Read first in every workflow
- Updated after every significant action
- Contains digest of accumulated context
- Enables instant session restoration
Creation: After ROADMAP.md is created (during init)
- Reference PROJECT.md (read it for current context)
- Initialize empty accumulated context sections
- Set position to "Phase 1 ready to plan"
Reading: First step of every workflow
- progress: Present status to user
- plan: Inform planning decisions
- execute: Know current position
- transition: Know what's complete
Writing: After every significant action
- execute: After SUMMARY.md created
- Update position (phase, plan, status)
- Note new decisions (detail in PROJECT.md)
- Add blockers/concerns
- transition: After phase marked complete
- Update progress bar
- Clear resolved blockers
- Refresh Project Reference date
Project Reference
Points to PROJECT.md for full context. Includes:
- Core value (the ONE thing that matters)
- Current focus (which phase)
- Last update date (triggers re-read if stale)
Claude reads PROJECT.md directly for requirements, constraints, and decisions.
Current Position
Where we are right now:
- Phase X of Y — which phase
- Plan A of B — which plan within phase
- Status — current state
- Last activity — what happened most recently
- Progress bar — visual indicator of overall completion
Progress calculation: (completed plans) / (total plans across all phases) × 100%
Performance Metrics
Track velocity to understand execution patterns:
- Total plans completed
- Average duration per plan
- Per-phase breakdown
- Recent trend (improving/stable/degrading)
Updated after each plan completion.
Accumulated Context
Decisions: Reference to PROJECT.md Key Decisions table, plus recent decisions summary for quick access. Full decision log lives in PROJECT.md.
Pending Todos: Ideas captured via /gsd-add-todo
- One bullet per pending todo, rendered by
init.todos'spending_todos_markdown(each bullet capped at 240 characters:- [date] [area] title — [todo file](path) — Needs ...; the todo-file link is repo-relative, so the cap does not depend on checkout path length) None yet.when there are no pending todos- No collapse-by-count fallback — every pending todo gets its own line, always (see #2618 design doc for why a "count if many" fallback was rejected)
Blockers/Concerns: From "Next Phase Readiness" sections
- Issues that affect future work
- Prefix with originating phase
- Cleared when addressed
Session Continuity
Enables instant resumption:
- When was last session
- What was last completed
- Is there a .continue-here file to resume from
<size_constraint>
Keep STATE.md under 100 lines.
It's a DIGEST, not an archive. If accumulated context grows too large:
- Keep only 3-5 recent decisions in summary (full log in PROJECT.md)
- Keep only active blockers, remove resolved ones
The goal is "read once, know where we are" — if it's too long, that fails.
</size_constraint>