Claude Code skills, rules, and language bundles https://git.cjennings.net/rulesets/atom?h=main 2026-06-13T06:38:42+00:00 2026-06-13T06:38:42+00:00 Craig Jennings c@cjennings.net 2026-06-13T06:38:42+00:00 urn:sha1:62cd707c2b78508e35177f553b72258ac6114198 All six decisions resolved. The router's input is filed keepers that belong to another project, not raw inbox files (Reading B). That keeps it a separate sub-step from the inbox gate (D1) and distinct from the defer-and-stage router (D5). Transcript routing is deferred to vNext (D4). I reworked the design to match: the input definition, a candidate-set note bounding the router to session-filed keepers rather than the standing backlog, and Phase 3. The cookie reads [6/6] and the Status moved to ready for review. The A-vs-B input ambiguity was the root under D1 and D5. Reading B keeps the inbox gate, the router, and defer-and-stage each simple instead of entangling all three. 2026-06-13T06:26:17+00:00 Craig Jennings c@cjennings.net 2026-06-13T06:26:17+00:00 urn:sha1:7b65b2dd04d97c2dc34e5afa715a07ce14b851ae A spec for the optional wrap-up step that routes inbox items (and, vNext, transcripts) to the project they belong to. Three decisions settled from grounding (reuse todo-cleanup's Open Work matcher as the destination anchor, move atomically through one helper, keep cross-project writes visible with a provenance note); three left open for Craig (separate router step vs merged into the inbox sanity check, transcript scope and trigger, reconciling with the defer-and-stage router). Five implementation phases, acceptance criteria, readiness dimensions. Status stays draft while decisions are open. The todo task moves to DOING and links the spec. From the archsetup handoff 2026-06-13. 2026-06-13T06:18:11+00:00 Craig Jennings c@cjennings.net 2026-06-13T06:18:11+00:00 urn:sha1:049aafb512e735dc04b77274c2167a67eec4f99f A wrap-up router that surfaces outstanding inbox items, recommends a destination project for each, and batch-moves task items into that project's todo.org, with a parallel transcript-filing step. I captured it as a design source and filed a spec-bound feature task rather than building it now: the work clears the spec bar, with design uncertainty (merge or stay separate from the inbox sanity check, recommendation-engine confidence, an unresolved transcript source-location dependency) and overlap with this session's defer-and-stage router to reconcile. From the archsetup handoff 2026-06-13. 2026-06-12T07:47:22+00:00 Craig Jennings c@cjennings.net 2026-06-12T07:47:22+00:00 urn:sha1:006711142e4a23da4fc990dc1371807d6200a74e The re-review confirmed every disposition with no new high or medium findings: Phase 1.5 stands at Ready with caveats, phases 2-5 stay parked behind the decisions fence. The response is correspondingly small — the accepted editorial rename of the Emacs subsection (its "open issue / blocks readiness" heading outlived the body, which is now an integration contract) and the second-pass note in the dispositions section. The updated review file and its history and task-tracking edits ride along. 2026-06-12T07:24:01+00:00 Craig Jennings c@cjennings.net 2026-06-12T07:24:01+00:00 urn:sha1:22e19c21e6aabe0319d4b09a862f4a3705c92509 The review's top finding was that one Not-ready label hid an implementable slice. Status now splits by arc: Phase 1.5 helper instances are READY WITH CAVEATS (the three-ring gate and the manual drills are binding, and the ai-term.el work is a coordinated .emacs.d handoff with an exact artifact), while phases 2-5 stay NOT READY behind a decisions-required section and a Phase 5 reverification prerequisite that demotes the model table to a recommendation. The remaining findings hardened the slice: per-ring rollback actions including the half-propagated-sync case, the review's test inventory adopted as normative, a message contract for stale helper files, and explicit roster-unavailable behavior on unsupported platforms. All recommendations accepted except the document split, modified to a dual rubric in one document. The review file and dispositions table ride along. 2026-06-12T04:09:38+00:00 Craig Jennings c@cjennings.net 2026-06-12T04:09:38+00:00 urn:sha1:c6fd73441ef0b683abb859863dcd0d48377a4838 2026-06-12T04:05:56+00:00 Craig Jennings c@cjennings.net 2026-06-12T04:05:56+00:00 urn:sha1:6f42f3c0ec5253d12182c0ad9f3d4efcca049420 The detection and identity subsections were authored under one design and patched under two others. They're now three pieces: the roster as the single detection primitive, two spawn paths (deterministic launcher, startup safety net) sharing the same three steps, and identity plus the role contract, with helper-mode.org named the single home of the helper rules. Verified ai-term.el's launch mechanics in code: the startup instruction is embedded in the tmux new-session command string, so env injection is a prefix on that string, and the -A flag means one session per project, so the helper path needs its own session and buffer names. Added ai-term recommendations to ride the same handoff (roster-derived badges, agent-exit visibility, one source for opener strings) and reconciled the v0 session-context symlink question with the Phase 1.5 answer. 2026-06-12T02:51:22+00:00 Craig Jennings c@cjennings.net 2026-06-12T02:51:22+00:00 urn:sha1:deea1d5821e6f52b8417a1d50cdfe53cad1022cd The first draft of the Emacs open issue assumed eat/vterm and invented an ai --no-tmux mode for a tmux-less path that doesn't exist. Verified against the actual config: the terminal is ghostel (native emulator over libghostty-vt), and ai-term.el is already the Emacs AI launch surface, creating project-named aiv- tmux sessions with liveness badges and crash recovery. Emacs-born agents are therefore tmux-parented like shell launches, so detection is uniform across surfaces. The remaining design is integration, not a new surface: ai-term.el's session-create learns the roster, export, and opener steps, the picker gains a [helper] badge, and the launchers share only the agent-roster script since ai-term owns its own session naming and window placement. 2026-06-12T01:09:21+00:00 Craig Jennings c@cjennings.net 2026-06-12T01:09:21+00:00 urn:sha1:53cfd886d3594c60aaa14b07a3077c124c756ba5 Two gaps block implementation. Sessions are also born from Emacs terminal buffers, where roster detection works (the scan matches process cwd, and eat/vterm shells are children of emacs) but the deterministic spawn path doesn't exist; the open issue weighs an elisp command against shelling out to ai with a no-tmux mode, leaning to the latter so the logic lives once. Second, template sync makes "live everywhere" the default failure mode for startup.org changes, so the test strategy gains three-ring gating: bats with sleeper processes and a byte-identical no-op guarantee, a disposable sandbox project for the corruption, orphaned-helper, and raw-launch drills, then a dormant-by-construction pilot through project-scripts before the template-wide release. The Status section carries the readiness checklist and the implementation task is blocked on it. 2026-06-12T01:05:16+00:00 Craig Jennings c@cjennings.net 2026-06-12T01:05:16+00:00 urn:sha1:65b99e86d570e489bcd91f377b71193cd7eaba44 The launcher becomes the spawn mechanism: a shell script runs the roster check, assigns the id, and launches with the helper instructions in order, where a model-followed startup instruction can skip a step. The in-session roster check stays as the safety net for raw launches and still splits a live anchor into crashed versus concurrent. Session-end ordering was unhandled: a helper outliving the primary stranded a dirty worktree, since the helper may not commit and the agent allowed to is gone. The git ban on helpers is concurrency-scoped, so it lifts when the helper finds itself alone at wrap-up and the last agent out closes the door with the full wrap-up. The mirror case pauses too: a primary wrapping with live helpers stops at the commit and asks whether to sweep the helper's in-flight work, wait, or leave closing to the helper.