From 3a933a26c12b6350fa46faf89bf86e99bfab0f30 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Tue, 28 Jul 2026 21:18:12 -0500 Subject: docs: record the references/ analysis and reverse its recommendation I first read winvm's dead-link finding as "add references/ to the rsync". Looking at what the directory holds reversed it. It has one file, protocols.org:273 is its only citation in the tree, and the four calendar workflows already sync and already carry the operational detail those recipes exist for. What the reference uniquely adds is credential file locations, which matter during a re-auth I do myself. So a new synced directory carrying --delete semantics, to deliver one mostly-redundant file, is a poor trade. Pinned for Craig's decision with all three options written out. --- todo.org | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/todo.org b/todo.org index b59c433..21e1e98 100644 --- a/todo.org +++ b/todo.org @@ -68,9 +68,19 @@ Source: home handoff, 2026-07-28. Grading: Minor severity (a documented reference an agent can't follow, workaround is to search or ask) x every user every time (every consuming project, every sync) = P2 = [#B]. -Two ways out: add =references/= to the rsync set, or drop the link and keep the file rulesets-only. My read is add it to the sync, because the link exists precisely so a session in another project can reach the calendar recipes. +Pinned 2026-07-28 for Craig's decision. Analysis below is complete; only the choice is open. -The =--delete= hazard I expected is not there. work is the only project with a =.ai/references/=, and its copy is byte-identical to the source (=diff -rq= clean), so nothing project-owned would be destroyed. Any *new* project-owned file under =references/= would be, which is the same tradeoff =workflows/= and =scripts/= already carry. +*Revised recommendation: drop the link, don't add the sync.* My first read was add =references/= to the rsync. Looking at what the directory actually holds reversed it: + +- =references/= holds exactly one file, and =protocols.org:273= is its only citation anywhere in the tree. +- The four calendar workflows (=add-=, =edit-=, =delete-=, =read-calendar-event(s).org=) already sync to every project, and already carry the operational detail: the MCP server name, both account IDs, the gcalcli fallback, conflict-checking. None of them cites =calendar-reference.org=; they are self-sufficient. +- What the reference uniquely adds is credential *file locations* (an OAuth keys path, a GPG-encrypted gcalcli secret) — no secret values. Re-auth is a rare operation Craig performs himself, not something an agent in another project needs a pointer to. + +So adding a synced directory carrying =--delete= semantics, to deliver one mostly-redundant file, is a poor trade. It also cuts against the rightsizing work: =protocols.org= is read into context every session, and a dead link is noise in a file being slimmed. + +Preferred fix: replace the link with a one-line pointer to the calendar workflows, which travel and are current. The reference file stays rulesets-only for the credential locations. + +Alternatives if Craig prefers: add =references/= to the rsync (the =--delete= hazard is not present today — work is the only project with a =.ai/references/= and its copy is byte-identical), or fold the credential locations into the calendar workflows and then drop the link (most complete, but spreads local absolute paths across four more synced files). Not =:solo:= — it changes a synced template, which needs Craig's approval by the inbox rule, and the sync-vs-drop choice is his. -- cgit v1.2.3