diff options
Diffstat (limited to 'todo.org')
| -rw-r--r-- | todo.org | 101 |
1 files changed, 52 insertions, 49 deletions
@@ -34,6 +34,58 @@ Tags are assigned and refreshed by =task-audit=; =task-review= keeps them honest * Rulesets Open Work +** TODO [#C] task-review pass at end of task-audit :chore:solo: +Have the =task-audit= workflow chain a =task-review= pass as its final phase, so a freshly-audited list also gets the lighter staleness/honesty sweep without a second invocation. The legend already notes the division of labor — task-audit assigns and refreshes tags, task-review keeps them honest in passing — so running task-review at the tail of task-audit closes the loop in one pass. Edit =claude-templates/.ai/workflows/task-audit.org= (and the synced mirror) to add the final phase; check whether =open-tasks.org= already invokes task-review so the chaining stays consistent. + +** TODO [#B] Cross-project pattern catalog :spec:thinking: +:PROPERTIES: +:LAST_REVIEWED: 2026-05-28 +:END: + +From pearl handoffs [[file:docs/design/2026-05-27-pattern-catalog-pearl-notes.org][2026-05-27]] + [[file:docs/design/2026-05-28-pattern-catalog-no-empty-input.org][2026-05-28 follow-up]]. + +Meta-question: how do good patterns travel from project A to project B? Pearl shipped three worked examples worth capturing — one-prompt picker with typed prefix (pearl-pick-source), magit-transient state buttons, and "no empty input as meaningful" (none-sentinel as first candidate). Each is a small principle with wide surface area; without a catalog, every project re-derives them from scratch. + +Open design questions before any implementation: +- Catalog format — structured (one pattern per file with frontmatter) vs free-form doc +- Surfacing mechanism — agent-driven (model spots opportunity) vs human-driven (Craig grep-searches) +- Anti-patterns included or only what worked +- Intake cadence — every time one lands, or batch review +- Home — rulesets repo (agent visibility) vs Linear doc vs per-project cross-links + +Pearl recommends a one-page spec (problem + design + open questions + acceptance) before implementation. Pearl available to come back for spec-review iterations. + +*** 2026-05-28 Thu @ 08:12:55 -0500 Pearl shipped patterns 4-6, filed alongside the prior two +Three more pearl handoffs landed and were filed during this audit. Filed: [[file:docs/design/2026-05-28-pattern-catalog-prompt-labels-and-defaults.org][prompt-labels-and-defaults]] (patterns 4-5: label-matches-behavior, default-most-common with friction-proportional-to-consequence) and [[file:docs/design/2026-05-28-pattern-catalog-prompt-collapse.org][prompt-collapse]] (pattern 6: collapse N orthogonal prompts into one enriched prompt). The catalog's evidence base is now four pearl notes in =docs/design/= covering six patterns plus the synthesizing principle Pearl articulated — "choices on screen, accurately labeled, ordered by what the user most often wants, friction sized to the cost of being wrong." + +** TODO [#B] Add Signal MCP server (rymurr/signal-mcp) :feature: +SCHEDULED: <2026-05-29 Fri> +:PROPERTIES: +:CREATED: [2026-05-29 Fri] +:LAST_REVIEWED: 2026-05-29 +:END: + +Install [[https://github.com/rymurr/signal-mcp][rymurr/signal-mcp]] so Claude can call =send_message_to_user=, =send_message_to_group=, and =receive_message= natively rather than shelling out to the =page-signal= wrapper. Python, MCP framework, depends on =signal-cli= being configured locally. + +Two-way capability is the differentiator over the CLI: =receive_message= lets the agent listen for replies on the phone, enabling page-as-confirm flows, "should I proceed?" loops over Signal, and structured Q&A across devices. + +*** Dependency + +This depends on the Google Voice account being registered with =signal-cli= first. Sending from Craig's primary number to itself doesn't notify (Signal treats it as one account on linked devices). The MCP server takes =--user-id= at startup, one account per instance, so it has to point at the GV account, with the primary as the per-send recipient. + +If GV registration is still pending when this task runs, block here and surface that. + +*** Implementation + +- =mcp/servers.json= — add =signal-mcp= entry under stdio transport (=command=, =args=, optional =env= for the user-id pointer). +- =mcp/README.org= — document the signal-cli + GV-registration dependency and the user-id pattern. +- =mcp/secrets.env.gpg= — only if the MCP server's user-id needs to be encrypted (probably not; the GV number isn't a secret beyond being personal). +- Verify: =make install-mcp= followed by =make check-mcp= shows =signal-mcp ok=; smoke-test via a Claude tool call sending a message + waiting on =receive_message=. + +*** Why this matters + +=page-signal= is the fast path (a hook, a script, a make recipe can call it without an MCP round-trip). The MCP server is the smart path. When Claude wants to send and then *react to the reply*, the CLI can't do that — only the MCP server can. The two complement each other; this task adds the second half. + ** TODO [#C] Check that memories are sync'd across machines via git :spec: :PROPERTIES: :LAST_REVIEWED: 2026-05-28 @@ -1074,27 +1126,6 @@ The flow tonight worked but took a handful of manual steps. One script collapses Decision (Craig, 2026-05-31): *hold until a token rotation is imminent.* The OAuth re-grant is a browser step that can't be triggered without revoking a live token, so the script can't be verified in isolation. Not marked =:solo:= — when a token actually needs rotating, write and verify in one pass (solo at that point). -** TODO [#B] Cross-project pattern catalog :spec:thinking: -:PROPERTIES: -:LAST_REVIEWED: 2026-05-28 -:END: - -From pearl handoffs [[file:docs/design/2026-05-27-pattern-catalog-pearl-notes.org][2026-05-27]] + [[file:docs/design/2026-05-28-pattern-catalog-no-empty-input.org][2026-05-28 follow-up]]. - -Meta-question: how do good patterns travel from project A to project B? Pearl shipped three worked examples worth capturing — one-prompt picker with typed prefix (pearl-pick-source), magit-transient state buttons, and "no empty input as meaningful" (none-sentinel as first candidate). Each is a small principle with wide surface area; without a catalog, every project re-derives them from scratch. - -Open design questions before any implementation: -- Catalog format — structured (one pattern per file with frontmatter) vs free-form doc -- Surfacing mechanism — agent-driven (model spots opportunity) vs human-driven (Craig grep-searches) -- Anti-patterns included or only what worked -- Intake cadence — every time one lands, or batch review -- Home — rulesets repo (agent visibility) vs Linear doc vs per-project cross-links - -Pearl recommends a one-page spec (problem + design + open questions + acceptance) before implementation. Pearl available to come back for spec-review iterations. - -*** 2026-05-28 Thu @ 08:12:55 -0500 Pearl shipped patterns 4-6, filed alongside the prior two -Three more pearl handoffs landed and were filed during this audit. Filed: [[file:docs/design/2026-05-28-pattern-catalog-prompt-labels-and-defaults.org][prompt-labels-and-defaults]] (patterns 4-5: label-matches-behavior, default-most-common with friction-proportional-to-consequence) and [[file:docs/design/2026-05-28-pattern-catalog-prompt-collapse.org][prompt-collapse]] (pattern 6: collapse N orthogonal prompts into one enriched prompt). The catalog's evidence base is now four pearl notes in =docs/design/= covering six patterns plus the synthesizing principle Pearl articulated — "choices on screen, accurately labeled, ordered by what the user most often wants, friction sized to the cost of being wrong." - ** TODO [#C] Generic agent runtime support — Codex spec v0 :spec:design: :PROPERTIES: :LAST_REVIEWED: 2026-05-28 @@ -1109,34 +1140,6 @@ Broader refactor proposes runtimes/ adapter manifests, generic install commands, Before any implementation: needs a real review pass on the spec, and a decision on whether to do Phase 1 alone (low risk, fixes the race) vs commit to the larger arc. -** TODO [#B] Add Signal MCP server (rymurr/signal-mcp) :feature: -SCHEDULED: <2026-05-29 Fri> -:PROPERTIES: -:CREATED: [2026-05-29 Fri] -:LAST_REVIEWED: 2026-05-29 -:END: - -Install [[https://github.com/rymurr/signal-mcp][rymurr/signal-mcp]] so Claude can call =send_message_to_user=, =send_message_to_group=, and =receive_message= natively rather than shelling out to the =page-signal= wrapper. Python, MCP framework, depends on =signal-cli= being configured locally. - -Two-way capability is the differentiator over the CLI: =receive_message= lets the agent listen for replies on the phone, enabling page-as-confirm flows, "should I proceed?" loops over Signal, and structured Q&A across devices. - -*** Dependency - -This depends on the Google Voice account being registered with =signal-cli= first. Sending from Craig's primary number to itself doesn't notify (Signal treats it as one account on linked devices). The MCP server takes =--user-id= at startup, one account per instance, so it has to point at the GV account, with the primary as the per-send recipient. - -If GV registration is still pending when this task runs, block here and surface that. - -*** Implementation - -- =mcp/servers.json= — add =signal-mcp= entry under stdio transport (=command=, =args=, optional =env= for the user-id pointer). -- =mcp/README.org= — document the signal-cli + GV-registration dependency and the user-id pattern. -- =mcp/secrets.env.gpg= — only if the MCP server's user-id needs to be encrypted (probably not; the GV number isn't a secret beyond being personal). -- Verify: =make install-mcp= followed by =make check-mcp= shows =signal-mcp ok=; smoke-test via a Claude tool call sending a message + waiting on =receive_message=. - -*** Why this matters - -=page-signal= is the fast path (a hook, a script, a make recipe can call it without an MCP round-trip). The MCP server is the smart path. When Claude wants to send and then *react to the reply*, the CLI can't do that — only the MCP server can. The two complement each other; this task adds the second half. - ** TODO [#C] Build Craig's writing voice profile from real corpora :spec: :PROPERTIES: :CREATED: [2026-05-29 Fri] |