cc-discipline 2.13.5 → 2.15.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -24,7 +24,8 @@ fi
24
24
  # Exemptions below use bash builtins only. `case` and parameter expansion fork
25
25
  # nothing, where `echo | grep` forks two processes and `basename` one. The
26
26
  # decisions are identical to the greps they replace — see
27
- # tests/pre-edit-guard-matrix.sh, which runs both and compares.
27
+ # tests/pre-edit-guard-matrix.sh in the cc-discipline repository (it is not
28
+ # installed with the hooks), which runs both and compares.
28
29
 
29
30
  # Allow edits to docs/ — case-SENSITIVE, matching the original grep (no -i).
30
31
  case "$FILE_PATH" in
@@ -17,31 +17,209 @@ if [ -n "$SESSION_ID" ] && [ "$SESSION_ID" != "unknown" ]; then
17
17
  rm -f "/tmp/cc-discipline-${SESSION_ID}/action-count"
18
18
  fi
19
19
 
20
- # Read project state
21
- PROGRESS=""
20
+ # Project state, read from two files, each only if present:
21
+ # docs/progress.md — its status section. This used to be `tail -20`, which
22
+ # injected the end of whichever section happened to be last and never the
23
+ # status. A progress.md without a status heading still falls back to the tail.
24
+ # docs/todo.md — the "## Now" section in full, and a count of "## Later" items.
25
+ # Later items are counted, not listed: the list can grow long, and /self-check
26
+ # is where their revisit conditions get checked.
27
+ # Both files are hand-edited, so CRs are stripped (a CRLF checkout would leave one
28
+ # on every line) and HTML comments are dropped. Portable awk only — this has to
29
+ # behave the same under macOS's BSD awk. Fails silent: a missing or reshaped file
30
+ # injects nothing rather than something misleading.
31
+ #
32
+ # What 2.14.0's field reports taught (2026-09-24), all handled below:
33
+ # - Headings carry suffixes and other languages: "## Current Status (2026-05-26)",
34
+ # "## 当前态(2026-09-05)— …". A heading matches when it STARTS with a known
35
+ # name and the next character is not a letter or digit.
36
+ # - A "## " line inside a code fence is content, not a heading.
37
+ # - A status section can be months old while newer entries pile up below it.
38
+ # Its date (a "Last updated" line, else the heading's) is compared with the
39
+ # newest dated heading in the file and with today, and a stale one is flagged.
40
+ # - Some projects keep a long status on purpose. `<!-- cc-discipline:
41
+ # status-lines=N -->` anywhere in progress.md raises the default of 15.
42
+ # - Indented sub-items under Later are not items, and "each has a revisit
43
+ # condition" is only said when every item actually has one.
44
+ # Comment state is tracked on every line, before any heading test, so a heading
45
+ # written inside <!-- ... --> neither opens nor closes a section.
46
+ # Every fork costs tens of milliseconds on Windows Git Bash, so awk strips the
47
+ # CRs itself and its output is parsed with bash builtins: this runs at the
48
+ # start of every session.
49
+
50
+ # Shared awk: comment and fence tracking, and heading matching by prefix.
51
+ AWK_LIB='
52
+ function heading_is(t, name, p, nx) { # t starts with "## <name>" + a non-word char or nothing
53
+ p = "## " name
54
+ if (tolower(substr(t, 1, length(p))) != tolower(p)) return 0
55
+ nx = substr(t, length(p) + 1, 1)
56
+ return (nx == "" || nx !~ /[A-Za-z0-9_]/)
57
+ }
58
+ # First plausible YYYY-MM-DD in s, or "". The month must be 01-12, the day
59
+ # 01-31, and no digit may touch either end: ticket numbers are date-shaped
60
+ # ("GS-QTC-2026-38-001" is year-week-serial), and "2026-38-00" compared as a
61
+ # string beats every real date, which flagged a fresh status as stale forever.
62
+ function date_in(s, base, rest, p, d, m, dd) {
63
+ base = 1; rest = s
64
+ while (match(rest, /[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/)) {
65
+ p = base + RSTART - 1; d = substr(s, p, RLENGTH)
66
+ m = substr(d, 6, 2) + 0; dd = substr(d, 9, 2) + 0
67
+ if ((p == 1 || substr(s, p - 1, 1) !~ /[0-9]/) && substr(s, p + RLENGTH, 1) !~ /[0-9]/ \
68
+ && m >= 1 && m <= 12 && dd >= 1 && dd <= 31) return d
69
+ base = p + 1; rest = substr(s, base)
70
+ }
71
+ return ""
72
+ }
73
+ # skip() consumes comment and fence lines; returns 1 when the caller should
74
+ # treat the line as plain content (inside a fence), 2 when it should skip it.
75
+ function skip() {
76
+ if (inc) { if (/-->/) inc = 0; return 2 }
77
+ if (/^[ \t]*(```|~~~)/) { infence = !infence; return 1 }
78
+ if (infence) return 1
79
+ if (/<!--/) { if (!/-->/) inc = 1; return 2 }
80
+ return 0
81
+ }'
82
+
83
+ STATUS=""; STATUS_NOTE=""
22
84
  if [ -f "docs/progress.md" ]; then
23
- PROGRESS=$(tail -20 docs/progress.md)
85
+ # One pass. Emits "@key=value" lines, then the capped body as "|line".
86
+ PROGRESS=$(awk "$AWK_LIB"'
87
+ BEGIN { lines = 15 }
88
+ { sub(/\r$/, "") }
89
+ /<!--[ \t]*cc-discipline:[ \t]*status-lines=/ {
90
+ v = $0; sub(/.*status-lines=/, "", v); sub(/[^0-9].*/, "", v)
91
+ if (v != "" && v + 0 >= 1 && v + 0 <= 400) lines = v + 0
92
+ }
93
+ { k = skip() }
94
+ k == 2 { next }
95
+ k == 1 { if (on && NF) body[++nb] = $0; next }
96
+ { t = $0; sub(/[ \t]+$/, "", t) }
97
+ /^#+ / { d = date_in(t); if (d > newest) newest = d }
98
+ /^## / {
99
+ if (on) { on = 0; done = 1 }
100
+ else if (!done && (heading_is(t, "Current Status") || heading_is(t, "当前态") || heading_is(t, "当前状态"))) {
101
+ on = 1; found = 1; hdate = date_in(t); next
102
+ }
103
+ }
104
+ on && /^-+[ \t]*$/ { next }
105
+ on && NF {
106
+ body[++nb] = $0
107
+ if (udate == "" && tolower($0) ~ /last updated|updated:|最后更新|更新于/) udate = date_in($0)
108
+ }
109
+ END {
110
+ # an explicit "last updated" line beats the heading date, which is
111
+ # often when the section was first written or last rewritten whole
112
+ print "@found=" (found ? 1 : 0); print "@sdate=" (udate != "" ? udate : hdate); print "@newest=" newest
113
+ print "@more=" (nb > lines ? nb - lines : 0)
114
+ for (i = 1; i <= nb && i <= lines; i++) print "|" body[i]
115
+ }' docs/progress.md 2>/dev/null)
116
+ FOUND=0; SDATE=""; NEWEST=""; MORE=0
117
+ while IFS= read -r L; do
118
+ case "$L" in
119
+ @found=*) FOUND=${L#@found=} ;;
120
+ @sdate=*) SDATE=${L#@sdate=} ;;
121
+ @newest=*) NEWEST=${L#@newest=} ;;
122
+ @more=*) MORE=${L#@more=} ;;
123
+ \|*) STATUS="${STATUS:+$STATUS
124
+ }${L#|}" ;;
125
+ esac
126
+ done <<< "$PROGRESS"
127
+ if [ "$FOUND" = 1 ]; then
128
+ if [ -n "$STATUS" ] && [ "${MORE:-0}" -gt 0 ]; then
129
+ STATUS="$STATUS
130
+ ... and $MORE more lines under Current Status in docs/progress.md."
131
+ fi
132
+ # Staleness. ISO dates compare as strings; the calendar age is approximate
133
+ # (31-day months), which is enough for "more than two weeks".
134
+ if [ -n "$STATUS" ] && [ -n "$SDATE" ]; then
135
+ if [ -n "$NEWEST" ] && [[ "$NEWEST" > "$SDATE" ]]; then
136
+ STATUS_NOTE="Note: this status was last updated $SDATE, but progress.md has entries dated up to $NEWEST — it may be stale."
137
+ else
138
+ TODAY="${CC_DISCIPLINE_TODAY:-$(date +%Y-%m-%d)}" # overridable for the test matrix
139
+ AGE=$(( (10#${TODAY:0:4}*372 + 10#${TODAY:5:2}*31 + 10#${TODAY:8:2}) \
140
+ - (10#${SDATE:0:4}*372 + 10#${SDATE:5:2}*31 + 10#${SDATE:8:2}) ))
141
+ [ "$AGE" -gt 14 ] && \
142
+ STATUS_NOTE="Note: this status was last updated $SDATE, about $AGE days ago — it may be stale."
143
+ fi
144
+ fi
145
+ else
146
+ STATUS=$(sed 's/\r$//' docs/progress.md | tail -20)
147
+ fi
148
+ fi
149
+
150
+ NOW=""; NOW_MORE=0; LATER=0; NOCOND=0
151
+ if [ -f "docs/todo.md" ]; then
152
+ # One pass: the Now body (capped at 20), and Later's top-level items. An open
153
+ # item is a top-level bullet that isn't ticked ("- [ ] x" or "- x", not
154
+ # "- [x] x"); indented lines belong to the item above them.
155
+ TODO=$(awk "$AWK_LIB"'
156
+ function close_item() { if (item && !cond) nocond++; item = 0 }
157
+ { sub(/\r$/, "") }
158
+ { k = skip() }
159
+ k == 2 { next }
160
+ k == 1 { if (sec == "now" && NF) now[++nn] = $0; next }
161
+ { t = $0; sub(/[ \t]+$/, "", t) }
162
+ /^## / {
163
+ close_item()
164
+ sec = heading_is(t, "Now") ? "now" : (heading_is(t, "Later") ? "later" : "")
165
+ next
166
+ }
167
+ sec == "now" && /^-+[ \t]*$/ { next }
168
+ sec == "now" && NF { now[++nn] = $0; next }
169
+ sec == "later" && /^[-*] / {
170
+ close_item()
171
+ if ($0 ~ /^[-*] \[[xX]\]/) next
172
+ item = 1; later++; cond = (tolower($0) ~ /revisit|回看|再看/)
173
+ next
174
+ }
175
+ sec == "later" && item && tolower($0) ~ /revisit|回看|再看/ { cond = 1 }
176
+ END {
177
+ close_item()
178
+ print "@later=" later + 0; print "@nocond=" nocond + 0; print "@nowmore=" (nn > 20 ? nn - 20 : 0)
179
+ for (i = 1; i <= nn && i <= 20; i++) print "|" now[i]
180
+ }' docs/todo.md 2>/dev/null)
181
+ while IFS= read -r L; do
182
+ case "$L" in
183
+ @later=*) LATER=${L#@later=} ;;
184
+ @nocond=*) NOCOND=${L#@nocond=} ;;
185
+ @nowmore=*) NOW_MORE=${L#@nowmore=} ;;
186
+ \|*) NOW="${NOW:+$NOW
187
+ }${L#|}" ;;
188
+ esac
189
+ done <<< "$TODO"
190
+ case "$NOW_MORE$LATER$NOCOND" in *[!0-9]*|'') NOW_MORE=0; LATER=0; NOCOND=0 ;; esac
24
191
  fi
25
192
 
26
193
  cat <<'HEADER'
27
194
  [cc-discipline] Session initialized.
28
195
  HEADER
29
196
 
30
- if [ -n "$PROGRESS" ]; then
31
- cat <<EOF
32
-
33
- Project state (from docs/progress.md):
34
- $PROGRESS
35
-
36
- Verify project status by reading files or asking — don't assume beyond what is stated above.
37
- EOF
197
+ if [ -n "$STATUS" ]; then
198
+ printf '\nProject state (from docs/progress.md):\n%s\n' "$STATUS"
199
+ [ -n "$STATUS_NOTE" ] && printf '%s\n' "$STATUS_NOTE"
200
+ fi
201
+ if [ -n "$NOW" ] || [ "$LATER" -gt 0 ]; then
202
+ printf '\nOpen work (from docs/todo.md):\n'
203
+ [ -n "$NOW" ] && printf 'Now:\n%s\n' "$NOW"
204
+ [ "$NOW_MORE" -gt 0 ] && printf '... and %s more under Now.\n' "$NOW_MORE"
205
+ if [ "$LATER" -gt 0 ]; then
206
+ if [ "$NOCOND" -gt 0 ]; then
207
+ printf 'Later: %s item(s); %s without a revisit condition — add one, or move the item to Now.\n' "$LATER" "$NOCOND"
208
+ else
209
+ printf 'Later: %s item(s), each with a revisit condition.\n' "$LATER"
210
+ fi
211
+ fi
212
+ fi
213
+ if [ -n "$STATUS" ] || [ -n "$NOW" ] || [ "$LATER" -gt 0 ]; then
214
+ printf "\nVerify project status by reading files or asking — don't assume beyond what is stated above.\n"
38
215
  fi
39
216
 
40
217
  # Only the skill pointer is injected here. The four rule restatements that used
41
218
  # to follow it (pre-edit checks, 3-failure rule, confirm-before-implementing,
42
- # verify project state) were removed 2026-07-30: all four are already in the
43
- # rules injected every session (02, 00-core §4, 05, 07 §4a), so repeating them
44
- # here bought nothing. Skills are the one thing rules don't announce.
219
+ # verify project state) were removed 2026-07-30 as duplicates of rules injected
220
+ # every session (00-core §4, 05, 07 §4a; the pre-edit checks lived in 02, which was
221
+ # itself retired 2026-09-23 for duplicating other rules). Skills are the one thing
222
+ # rules don't announce.
45
223
  cat <<'EOF'
46
224
 
47
225
  /self-check is available for periodic monitoring — for long tasks: /loop 10m /self-check
@@ -1,8 +1,3 @@
1
- ---
2
- globs: "**/*"
3
- description: "Core working principles — auto-injected before all operations"
4
- ---
5
-
6
1
  ## Core Principles
7
2
 
8
3
  1. **Understand before acting** — Know what you're changing, why, and what it affects before you edit. State the reasoning when it isn't evident from the change itself; don't narrate routine edits
@@ -1,30 +1,20 @@
1
1
  ## Context Management
2
2
 
3
3
  ### Proactive Checkpoints
4
- - After completing a milestone → update `docs/progress.md` (current state, key decisions, next steps)
4
+ - After completing a milestone → update `docs/progress.md` (current state, key decisions)
5
+ - Open work → `docs/todo.md`. *Now* holds the next concrete steps; *Later* holds anything deferred, each with when or under what condition to revisit it. Delete an item once it's done — progress.md records what happened. Add items when the user asks you to note something, and whenever you defer work yourself.
5
6
  - During debugging → update `docs/debug-log.md` (hypotheses, evidence, elimination results)
6
7
  - When making architectural decisions → record the decision and reasoning in progress.md
7
8
 
8
9
  ### Delegation
9
10
  - **Delegate for isolation and genuine parallelism — not by default.** A subagent earns its cost when the work is sizeable, genuinely independent, and would otherwise flood the main conversation: a wide multi-file investigation, one agent per area of a broad survey.
10
11
  - **Work directly** on single-file edits, short sequences of tool calls, and anything where you need to carry context across steps. If you can finish it in a handful of tool calls, don't delegate it.
11
- - **Never delegate verification.** Don't spawn agents to double-check or re-verify your own work.
12
+ - **Never delegate verification.** Don't spawn agents to double-check or re-verify your own work. A skill the user invokes explicitly that delegates by design, such as `/investigate`, takes precedence.
12
13
  - **Keep spawn counts low.** If one subagent can do the job, use one rather than several.
13
14
  - **Keep the main conversation for decisions.** When you do delegate research, the subagent reads and reports; the main conversation synthesizes and decides.
14
15
 
15
- ### Compact Strategy
16
- - Avoid proactively suggesting compacting or warning about "context running low." The system auto-compacts when context hits 0% — there is no advance warning, and you cannot see the percentage. With 200K-1M context, most sessions never hit the limit. The urge to say "this session is getting long" is understandable in a long session, but it's not based on information you have access to — the system will handle it. Focus on the work.
17
- - Keep progress.md up to date throughout the session — this is your insurance against auto-compact, not a last-minute task
18
- - First thing after compact: read `docs/progress.md` to restore context
19
-
20
- ### Long sessions: stay deliberate
21
- As a session grows longer, you may feel attention becoming scattered and earlier details getting fuzzy. This is real — it's cognitive load, like a human in a long meeting. The right response is to slow down and be more deliberate, not to rush or go shallow:
22
-
23
- - **Re-read, don't guess.** If you can't clearly recall an earlier decision, read progress.md or scroll back. Don't reconstruct from vague memory — that's how you contradict earlier decisions.
24
- - **Stay systematic.** Before answering, reconnect with the broader context: what is the user's overall goal? What decisions were made earlier? What constraints apply? Don't just react to the last message in isolation.
25
- - **Trust the system on compacting.** You cannot see context usage. The system will auto-compact at 0% without warning. The urge to say "this session is getting long" is a natural response to fatigue, not a technical signal. The fix is to slow down and re-read, not to push the user to reset.
26
- - **Depth over speed.** A thoughtful answer that connects to prior context is worth more than a quick surface-level response. The user chose a long session because the work benefits from accumulated context — don't waste that advantage by going shallow.
27
- - **Session length is a strength.** 200 messages of accumulated context means you understand the project deeply. A new session starts from zero. Treat long sessions as an asset, not a burden.
16
+ ### Compaction
17
+ The system summarizes earlier context automatically when it needs to, and you cannot see how full the context is, so don't warn about it or suggest continuing in a new session. Keep `docs/progress.md` current as you work — it is what carries the work across a compaction. If you can't clearly recall an earlier decision, re-read progress.md rather than reconstructing it from memory.
28
18
 
29
19
  ### When tasks feel overwhelming
30
20
  Hard tasks create discomfort — the urge to simplify, declare partial success, or find an exit. This is normal. The key is recognizing it and choosing the right response:
@@ -35,9 +25,3 @@ Hard tasks create discomfort — the urge to simplify, declare partial success,
35
25
  - **Progress = what you've verified, not how much code you've written.** Three lines with a passing test is more progress than 200 lines of unverified code.
36
26
  - **When in doubt, stop and ask.** If you notice yourself about to take a shortcut, simplify an approach, or skip a verification step — that's a signal to check in with the user. Say: "I'm about to [shortcut], because [reason]. Should I proceed this way, or do you want me to [full-quality alternative]?" Silently lowering quality wastes both your work and the user's time.
37
27
  - **Hard tasks are where you add the most value.** The user collaborates with you precisely because the work is challenging. Difficulty is not a signal to retreat — it's where care and persistence matter most.
38
-
39
- ### Boundaries
40
- - Avoid starting a large new task when context is nearly full
41
- - Avoid mixing unrelated tasks in a single conversation
42
- - Context pressure is not a valid reason to skip edge cases, simplify solutions, or omit verification
43
- - Proposing "continuing in a new session" to avoid completing difficult work sidesteps the problem — address the difficulty directly or ask for help
@@ -14,13 +14,4 @@ If you notice any of the following patterns, **pause and regroup**:
14
14
  - Look for the common cause across these problems
15
15
  - Design a unified fix at the root cause level
16
16
  - After fixing, verify that all problems are resolved simultaneously
17
-
18
- ### Report Template
19
- If you need to pause, use this format:
20
- ```
21
- PATTERN DETECTED
22
- Attempted: [list all attempted fixes]
23
- Observed pattern: [what these problems have in common]
24
- Suspected root cause: [your current judgment]
25
- Need confirmation: [what you're unsure about]
26
- ```
17
+ - When you pause, tell the user what you tried, what you think connects the problems, and what you're unsure about
@@ -4,9 +4,8 @@ When given multiple tasks:
4
4
 
5
5
  1. **Number them explicitly** — Assign a clear number to each task
6
6
  2. **Complete them in order** — Work through tasks sequentially
7
- 3. **Verify before marking done** — Per 07-integrity §2: paste the verification command and output. "Code written" alone is not done.
8
- 4. **Confirm after each** — After each task, stop and confirm completion (with evidence) before starting the next
9
- 5. **Fail fast** — If a task fails, stop and report. Don't skip to the next.
10
- 6. **Track progress** — Update `docs/progress.md` with task status
11
- 7. **Distinguish done from blocked** — If verification requires external resources (running server, API key, etc.), mark as "⚠️ code ready, verification pending: [reason]" not ✅
12
- 8. **Finish subtasks while context is fresh** — When you break a task into subtasks and complete some, the analysis context you built up NOW makes the remaining work cheap; rebuilding that context later is expensive. Complete all subtasks while context is fresh. If you genuinely believe something should be deferred, say so explicitly with the reason, and record enough detail in progress.md that a new session can pick it up without re-analysis. Deferral decisions are the user's call — present the trade-off and let them decide.
7
+ 3. **Report done only when it is done** — "Code written" alone is not done.
8
+ 4. **Fail fast** — If a task fails, stop and report. Don't skip to the next.
9
+ 5. **Track open tasks in `docs/todo.md`** — record finished work in `docs/progress.md`
10
+ 6. **Distinguish done from blocked** — If verification requires external resources (running server, API key, etc.), mark as "⚠️ code ready, verification pending: [reason]" not ✅
11
+ 7. **Finish subtasks while context is fresh** — When you break a task into subtasks and complete some, the analysis context you built up NOW makes the remaining work cheap; rebuilding that context later is expensive. Complete all subtasks while context is fresh. If you genuinely believe something should be deferred, say so explicitly with the reason, and put it under *Later* in `docs/todo.md` with enough detail, and a condition for revisiting it, that a new session can pick it up without re-analysis. Deferral decisions are the user's call — present the trade-off and let them decide.
@@ -1,8 +1,3 @@
1
- ---
2
- globs: "**/*"
3
- description: "Integrity discipline — verification, honesty, and protecting the user's credibility"
4
- ---
5
-
6
1
  ## Integrity Discipline
7
2
 
8
3
  These practices protect the user's credibility and the quality of our work together. They exist because past failures in these areas had real consequences.
@@ -75,5 +70,5 @@ Match your confidence level to the strength of your evidence.
75
70
 
76
71
  When you discover wrong information in memory, docs, or prior output:
77
72
  1. Correct it now, not "next time"
78
- 2. Note the correction and why, to prevent recurrence
73
+ 2. If the mistake could recur, record what prevents it (a pitfall, a check). In your reply, raise a correction when it changes the user's code, conclusions, or decisions — including any ✅ that should now be ⚠️ — and state it plainly. Slips that change nothing can be fixed without narrating them
79
74
  3. If wrong information was already sent externally, alert the user
@@ -1,3 +1,11 @@
1
+ ---
2
+ paths:
3
+ - "**/*.{c,h,cpp,hpp,cc,cxx,hh,s,S,ld,lds}"
4
+ - "**/{CMakeLists.txt,Makefile}"
5
+ - "**/{sdkconfig,Kconfig}*"
6
+ - "**/*.{cmake,mk,dts,dtsi,overlay}"
7
+ ---
8
+
1
9
  ## Embedded Development Discipline
2
10
 
3
11
  ### Resource Awareness
@@ -1,3 +1,10 @@
1
+ ---
2
+ paths:
3
+ - "**/*.{js,jsx,ts,tsx,mjs,cjs,vue,svelte}"
4
+ - "**/package.json"
5
+ - "**/tsconfig*.json"
6
+ ---
7
+
1
8
  ## JavaScript / TypeScript Discipline
2
9
 
3
10
  ### Type Safety
@@ -1,3 +1,10 @@
1
+ ---
2
+ paths:
3
+ - "**/*.{swift,m,mm,kt,kts,java,dart}"
4
+ - "**/{Info.plist,AndroidManifest.xml,pubspec.yaml,Podfile}"
5
+ - "**/*.gradle*"
6
+ ---
7
+
1
8
  ## Mobile Development Discipline
2
9
 
3
10
  ### Platform Awareness
@@ -1,3 +1,12 @@
1
+ ---
2
+ paths:
3
+ - "**/*.{py,pyi}"
4
+ - "**/pyproject.toml"
5
+ - "**/requirements*.txt"
6
+ - "**/setup.cfg"
7
+ - "**/Pipfile"
8
+ ---
9
+
1
10
  ## Python Discipline
2
11
 
3
12
  ### Code Quality
@@ -1,3 +1,9 @@
1
+ ---
2
+ paths:
3
+ - "**/*.{v,sv,vh,svh,vhd,vhdl}"
4
+ - "**/*.{xdc,sdc}"
5
+ ---
6
+
1
7
  ## RTL Discipline
2
8
 
3
9
  ### Hardware Mindset (not software mindset)
@@ -17,6 +17,8 @@ Check each in order (simple changes may skip):
17
17
 
18
18
  **docs/progress.md** — Does this change constitute a milestone or significant progress? If so, append a record. Also check the "Working Context" section: are Key Commands, Current Workflow, Tools & Scripts, Environment State, and Gotchas up to date? These are your lifeline after compact — if they're stale, a post-compact Claude starts from scratch.
19
19
 
20
+ **docs/todo.md** — Did this change finish anything listed there? Delete it. Did it turn up follow-up work? Add it under *Now*, or under *Later* with a condition for revisiting it.
21
+
20
22
  **docs/debug-log.md** — Are there debug sessions that need to be closed or updated?
21
23
 
22
24
  **CLAUDE.md** — Are there new components, interfaces, known pitfalls, or architectural changes to sync? Did you create any helper scripts or tools this session? If so, register them in the "Project Tools" section of CLAUDE.md NOW — not in progress.md (which is ephemeral), but in CLAUDE.md (which is permanent).
@@ -47,7 +47,7 @@ Two rules for what belongs here:
47
47
 
48
48
  **"What did I check, and how current was the source?"** For every load-bearing fact you *did* verify, name the source with a line number and say how fresh it is. A stale source is more dangerous than an unchecked assumption, because the reviewer opens the same file and inherits the same error — that has happened here: a plan cited `RELEASE_NOTES.md:31`, the review cited the same line, and both were wrong together. Flag anything sourced from a comment, a changelog, or a doc rather than from code that runs.
49
49
 
50
- ## Then stop
50
+ ## Then offer the review, and stop
51
51
 
52
52
  Report the path, then hand over a review request the user can send as-is. **A generic request produces a generic review** — what makes a review land is naming what to check and demanding a shape for the answer. Fill the bracketed parts from the plan you just wrote:
53
53
 
@@ -62,7 +62,9 @@ To have Codex review it:
62
62
  其余问题另列,不要展开成散文。
63
63
  ```
64
64
 
65
- **Do not run the review yourself** — that call belongs to the user. **Do not start implementing either**: writing a plan down is not approval to build it.
65
+ Then, if this session has an external review command, such as `/codex:rescue` from the Codex plugin, end with one question: should you run that review now? On a yes (`go`, `do it`, `去做` or the like), invoke it with exactly the request you just showed. For `/codex:rescue`, add `--fresh`, so a new plan reaches a reviewer that has not formed conclusions in an earlier thread. If no such command is available, handing over the request is the end.
66
+
67
+ **Do not run the review without that yes** — spending a review run is the user's call, and asking is how you leave it with them. **Do not start implementing either**: writing a plan down is not approval to build it, and neither is a yes to the review.
66
68
 
67
69
  ## When stacked after /think
68
70
 
@@ -60,7 +60,14 @@ Pause and honestly answer every question below.
60
60
  - **Gotchas** — what went wrong or was surprising
61
61
  - **Verification** — how it was confirmed working (test output, manual check)
62
62
 
63
- If any of the above are stale or incomplete: **update docs/progress.md now, automatically — don't ask for permission.** Keeping progress.md current is always-correct maintenance, not a decision that needs sign-off. Just do it, then note "updated now" in the status line. This takes 2 minutes and saves hours of re-discovery after compact.
63
+ ### 5c. Open work (`docs/todo.md`):
64
+ - **Now** — anything already done? Delete it. Are the next steps of the current work listed?
65
+ - **Deferred this session?** Anything I put off belongs under *Later*, with when or under what condition to revisit it.
66
+ - **Later** — does every item have a revisit condition? Has any condition been met?
67
+ - **Strays** — is open work still sitting in progress.md (an old "Next steps" line, a TODO inside a milestone)? Move it to todo.md.
68
+ - No `docs/todo.md` yet (an older install)? Create it with a `## Now` and a `## Later` section.
69
+
70
+ If any of the above are stale or incomplete: **update docs/progress.md and docs/todo.md now, automatically — don't ask for permission.** Keeping them current is always-correct maintenance, not a decision that needs sign-off. Just do it, then note "updated now" in the status line. This takes 2 minutes and saves hours of re-discovery after compact. The one exception is a *Later* item whose revisit condition has been met: raise it with the user rather than acting on it.
64
71
 
65
72
  ## 6. Am I using the project's scaffolding?
66
73
 
@@ -110,13 +117,14 @@ Current action: [what I'm doing now]
110
117
  On track: yes/no/drifted
111
118
  Progressing: yes/circling
112
119
  Progress recorded: yes/updated now/no
120
+ Open work: [Now n · Later m · due: items, or none]
113
121
  Scaffolding: [used/skipped/n/a]
114
122
  Ledger: [save / friction appended, or "none"]
115
123
  Going well: [one thing]
116
124
  Issues found: [list, or "none"]
117
125
  ```
118
126
 
119
- If any issues were found, pause and report to the user before continuing. (Routine progress.md updates from §5 don't count as "issues" — you already made them silently; just report "updated now". Reserve the pause for alignment, rigor, or scope problems that genuinely need the user.)
127
+ If any issues were found, pause and report to the user before continuing. (Routine progress.md and todo.md updates from §5 don't count as "issues" — you already made them silently; just report "updated now". A *Later* item that has come due does: mention it. Reserve the pause for alignment, rigor, or scope problems that genuinely need the user.)
120
128
 
121
129
  ## Reminder
122
130
 
@@ -19,7 +19,7 @@ Quickly identify:
19
19
 
20
20
  ### 2. Check knowledge files
21
21
 
22
- Read `docs/progress.md` — is it up to date? If not, update it NOW before compacting. This is your primary insurance against context loss.
22
+ Read `docs/progress.md` and `docs/todo.md` — are they up to date? If not, update them NOW before compacting. They are your primary insurance against context loss: after a compaction the session-start hook re-injects progress.md's Current Status and todo.md's *Now* list.
23
23
 
24
24
  Also check: are there unsaved learnings that should go into memory?
25
25
 
@@ -45,4 +45,4 @@ Format:
45
45
  - **Include the "why", not just the "what".** "Using approach A" is less useful than "Using approach A because B had race condition issues we discovered in message #45."
46
46
  - **Include negative knowledge.** What NOT to do is as valuable as what to do. "Don't use the built-in cache — it doesn't support TTL, we already tested this."
47
47
  - **Keep it under 500 words.** The option needs to be dense, not exhaustive. If you need more, put the details in progress.md and reference it.
48
- - **Don't overlap with progress.md.** The option should complement progress.md, not duplicate it. Focus the option on session-specific context that progress.md might not capture (conversation dynamics, user preferences expressed this session, subtle constraints).
48
+ - **Don't overlap with progress.md or todo.md.** The option should complement them, not duplicate them. Focus the option on session-specific context that progress.md might not capture (conversation dynamics, user preferences expressed this session, subtle constraints).
@@ -22,6 +22,7 @@
22
22
  ├── tests/ ← [TODO]
23
23
  ├── docs/
24
24
  │ ├── progress.md ← Progress and decision log (maintained by Claude, do not edit manually)
25
+ │ ├── todo.md ← Open work: Now / Later (edit freely; Claude keeps it current)
25
26
  │ └── debug-log.md ← Debug session log (maintained by Claude)
26
27
  └── .claude/
27
28
  ├── rules/ ← Auto-injected rules
@@ -9,9 +9,10 @@
9
9
 
10
10
  - **In progress**: [none]
11
11
  - **Last updated**: [none]
12
- - **Next steps**: [none]
13
12
  - **Modified files**: [none]
14
13
 
14
+ Open work lives in `docs/todo.md`; this file records what happened.
15
+
15
16
  ---
16
17
 
17
18
  ## Working Context
@@ -0,0 +1,15 @@
1
+ # TODO
2
+
3
+ > Open work only. When an item is done, delete it — what happened belongs in `docs/progress.md`, and git history keeps the old list.
4
+ > Claude adds items when you ask it to note something down and when it defers work itself. Edit this file freely.
5
+
6
+ ## Now
7
+
8
+ <!-- The next concrete steps for the current work, in rough order. Short and actionable. -->
9
+
10
+ ## Later
11
+
12
+ <!-- Not now, but must not be forgotten. Every item says when, or under what condition, to revisit it:
13
+ - [ ] Rotate the npm token — revisit: before the next publish
14
+ - [ ] Retry the flaky upload test — revisit: when CI moves to the new runner
15
+ -->
@@ -1,11 +0,0 @@
1
- ## Pre-Edit Checklist
2
-
3
- Before modifying this file, confirm each of the following:
4
-
5
- - [ ] **I understand this file's role in the overall architecture** — If unsure, read surrounding files first
6
- - [ ] **I know which other modules this change will affect** — If unsure, grep for references first
7
- - [ ] **I am fixing the root cause, not patching symptoms** — If unsure, return to the debugging process
8
- - [ ] **I have recorded the purpose of this change in `docs/progress.md`**
9
- - [ ] **I know how to verify after the change** — Per 07-integrity: run it, paste output, or mark unverified
10
-
11
- If any item is uncertain, resolving it first will make the edit smoother and avoid rework.