diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-29 18:45:45 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-29 18:45:45 -0500 |
| commit | 7e36d9d7a878ee592f7d21fa757ae9f6653446ca (patch) | |
| tree | 9410307d57d80bd107afbbdd86efe52b007518b3 | |
| parent | 506ab6e7f7b41097aaa832d168bd427788be3296 (diff) | |
| download | rulesets-7e36d9d7a878ee592f7d21fa757ae9f6653446ca.tar.gz rulesets-7e36d9d7a878ee592f7d21fa757ae9f6653446ca.zip | |
chore(intake): file startup-rsync-dirty TODO, stamp :LAST_INBOX_PROCESS:, clear processed inbox
The process-inbox workflow walked the four inbox arrivals (one from
home, one from jr-estate, two from health):
- 2026-05-28-0858 home spec-naming-convention: implemented in
bb28cfa. Deleted.
- 2026-05-29-0832 jr-estate startup-rsync-carried-dirty: filed as
[#B] :feature: TODO under Rulesets Open Work. Three options
captured (skip-when-dirty, clean-files-only, clean-ref-based) with
my recommendation noted. Deleted.
- 2026-05-29-1111 health org-drill-anki initial: superseded by 1114.
Deleted without filing.
- 2026-05-29-1114 health org-drill-anki updated: implemented in
506ab6e. Deleted.
The startup-rsync-dirty TODO also captures an anomaly the jr-estate
handoff flagged: even with --delete, two files that DO exist in
rulesets canonical (cross-project-broadcast.org, page-signal.org)
did NOT propagate. This is likely a timing issue (those files were
added after the jr-estate Phase A rsync ran). The anomaly is worth
confirming when the TODO is picked up.
notes.org Workflow State stamped :LAST_INBOX_PROCESS: 2026-05-29.
Inbox now empty.
| -rw-r--r-- | .ai/notes.org | 1 | ||||
| -rw-r--r-- | todo.org | 19 |
2 files changed, 20 insertions, 0 deletions
diff --git a/.ai/notes.org b/.ai/notes.org index 1389e02..062af89 100644 --- a/.ai/notes.org +++ b/.ai/notes.org @@ -79,5 +79,6 @@ Format: Markers maintained by workflows to record when they last ran. Read by other workflows that gate their behavior on freshness. :LAST_AUDIT: 2026-05-28 +:LAST_INBOX_PROCESS: 2026-05-29 Format: one =:MARKER: YYYY-MM-DD= line per workflow. Workflows overwrite their own marker on completion. @@ -1177,6 +1177,25 @@ Before any implementation: needs a real review pass on the spec, and a decision :LAST_REVIEWED: 2026-05-28 :END: +** TODO [#B] Startup Phase A rsync propagates dirty rulesets WIP into downstream projects :feature: +:PROPERTIES: +:CREATED: [2026-05-29 Fri] +:LAST_REVIEWED: 2026-05-29 +:END: + +From jr-estate handoff 2026-05-29. When rulesets has uncommitted WIP at the moment a downstream project starts a session, Phase A.0 reports "dirty, skipping pull" and proceeds. Phase A's =rsync -a --delete= then runs against the dirty rulesets working tree and copies the WIP state into the downstream project's =.ai/workflows/= and =.ai/scripts/=. The downstream project's =git status= then shows drift the user did not author. Two bad recovery paths: commit the drift as "chore: sync .ai tooling from templates" (creates fake commit history about template state) or leave it dirty (noisy wrap-ups, pressure to commit anyway). + +Three options proposed in the handoff: +1. *Skip-when-dirty.* Make Phase A's workflows/ and scripts/ rsync no-op when Phase A.0 reports rulesets dirty. Simplest defense. +2. *Clean-files-only.* Restrict the rsync to files git considers unmodified in rulesets. Untracked files in rulesets do not propagate. Most precise. +3. *Clean-ref-based.* Cache the last-known-clean state as a git tag or ref and rsync from that ref rather than the working tree. Most decoupled, also the most infrastructure. + +Recommendation (mine): option 1. The downstream impact of skipping a sync once is small (the next session with rulesets clean catches up), and the implementation is one =if [ "$dirty" -eq 0 ]= guard around the existing rsync block. Option 2 adds shellout complexity per file; option 3 requires tagging discipline that has no other reason to exist. + +The original handoff also noted a related anomaly: even with =--delete=, two files that DO exist in rulesets canonical (=cross-project-broadcast.org=, =page-signal.org=) did NOT propagate to jr-estate. Worth confirming whether that was a transient rsync issue or evidence of a deeper Phase A bug. Could be ordering: those files were added to rulesets AFTER the jr-estate Phase A rsync ran, in which case the behavior is correct and the report is misreading the timeline. + +Source: =inbox/2026-05-29-0832-from-jr-estate-investigate-startup-rsync-carried-dirty.org= (processed and deleted). + ** TODO [#B] Codex Phase 1 — AI_AGENT_ID + session-context.d/<id>.org :feature: :PROPERTIES: :CREATED: [2026-05-28 Thu] |
