lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(wolf): update anatomy index, cerebrum, and memory log

Browse source 
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYdtrEWWZfKRRGED7raEYg
This commit is contained in:
Rongsong Shen 2026-09-03 09:43:21 +00:00
parent 8557b86931
commit 7e46a32627
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
4 changed files with 21 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

1
.wolf/cerebrum.md
View file

@ -229,3 +229,4 @@
- **(2026-08-26, bug-1718, xce-test-rc-file task 3.1) A `python3 -` (or any "read program from stdin") invocation placed on the SAME command as a `<<HEREDOC` redirect while ALSO receiving piped input (`upstream | python3 - args <<EOF ... EOF`) silently loses the piped data, no error.** The heredoc redirect wins stdin over the pipe for that command; `python3 -` consumes the heredoc's content as its own program source, so by the time the script's own `sys.stdin.read()` runs, stdin is already at EOF — it just returns `""` with zero diagnostic. Caught by re-reading the draft before ever running it, not by a failing run. **Fix pattern: write the embedded program to its own temp file ONCE (`mktemp` + `cat >"$DRIVER" <<EOF...EOF`, cleaned via an `EXIT` trap), then invoke it as `upstream | python3 "$DRIVER" args...`** — a file argument doesn't compete with the pipe for stdin, unlike `-`. Applies to any interpreter's "read program from stdin" mode (`python3 -`, `perl -e -`, etc.) combined with a heredoc AND a real piped payload in the same pipeline.
- **(2026-08-26, xce-test-rc-file task 3.1) `xce_test`'s `cmd_set(argc==1)` (`set` with no args) is the generic, no-live-cluster-required readback for ANY setting** (`test.c:3684`, format `"%-12s:%s default: %s\n"`, `KVAL()` prints `"<not set>"` for a NULL current value) — the right primitive for any integration test that needs to observe an rc-file/`set`-driven setting change (e.g. `masters`) without a live controller connection. Don't hardcode the exact column padding when grepping its output (fragile) — extract via `sed -E 's/^masters[[:space:]]*:(.*) default:.*/\1/'` (greedy `(.*)` correctly captures the embedded-space `"<not set>"` sentinel too, since there's only one literal `" default:"` substring per line to anchor against).
- **(2026-08-26, xce-test-rc-file task 3.1) `xce_test` uses `libedit`'s `readline()`/`isatty(STDIN_FILENO)`-gated `g_interactive`, so a genuine interactive-mode integration test needs a REAL pty, not a piped stdin** — confirmed working via a small embedded Python `pty.fork()` driver (write commands to the master fd with a short settle delay after each, drain with `select()`, detect child exit via non-blocking `waitpid`, `os.waitstatus_to_exitcode()` for the real exit code). Same technique task 2.2's own implementer used for manual verification; this task turned it into a reusable scripted harness. The prompt itself (`fill_prompt`, top-level context) renders as literal `"xce>"` — grepping for that substring in the pty transcript is a good "this really was a TTY session, not a piped fallback" sanity check, distinct from the actual assertion under test.
- **A `.kiro/specs/*/tasks.md` checkbox count (`- [ ]` vs `- [x]`) is NOT reliable at face value when it includes section-HEADER checkboxes ("- [ ] N. Some phase name") — a spec whose every N.M subtask is `[x]` but whose parent `- [ ] N.` header was never flipped reads as "in progress" when it is actually 100% done.** (2026-09-03, cross-spec audit) Recurred a second time after the first fix (`5c82ad0b`, 2026-08-24, 5 specs): `scheduler-sim-eager-reconciliation` looked like "6/9, stalled since Aug 22" by a naive checkbox count, but all 3 "unchecked" items were section headers whose children (1.1/1.2/2.1/3.1/3.2/3.3) were already all `[x]`, with a `task 3.3 full regression confirmation` commit proving genuine completion on 2026-08-27. `worker-rejoin-resync` was the same drift the other direction (28/28 real tasks incl. headers all `[x]`, but `spec.json.phase` itself never advanced past `tasks-generated`). **Before reporting any spec as "stalled" or "N/M done," check headers and children SEPARATELY (`grep -E '^\s*-\s*\[ \]\s*[0-9]+\.'` for unchecked headers vs `^\s*-\s*\[ \]\s*[0-9]+\.[0-9]'` for unchecked subtasks) and cross-check `spec.json.phase`/`updated_at` against the tasks.md file's own git log — a low, stale-looking checkbox ratio and a phase field that hasn't moved are both metadata that can independently lag the real state, not just one signal.**