repo-dispatch: drop the docs/repo-dispatch markdown artifact, put context in the tracking issue #28

Open
opened 2026-05-23 20:55:24 +00:00 by coilysiren · 0 comments
Owner

Originally filed by @coilysiren on 2026-05-19T08:10:24Z - https://github.com/coilysiren/repo-recall/issues/200

Proposal. Stop writing the per-dispatch markdown artifact at docs/repo-dispatch/<slug>.md. Put all the frontmatter + prompt body directly into the tracking GitHub issue. One substrate, not two.

Why this fits the existing model. The substrate-hygiene rule in recall-dispatch SKILL.md already says: "No new state in repo-recall's local DB. Dispatch outcomes get derived from closed issues plus their commits." The markdown file is the one piece of dispatch state that isn't in GitHub. It already has a 1:1 tracking issue. Moving the prompt body into the issue body makes the substrate uniform and lets every consumer (planner, pickup, ingest, metrics) read one surface.

What changes:

  • Emitter side (recall-dispatch). Stop writing docs/repo-dispatch/<slug>.md. Create the tracking issue with label: repo-dispatch, title = the dispatch slug (or its description), body = the existing markdown (frontmatter as a fenced YAML block at the top, prompt verbatim below). Skip the file system entirely.
  • Pickup side (tooling-autonomous-pickup). Instead of scanning ~/.repo-recall/dispatch/<repo>/*.md and writing .handled sidecars, scan gh issue list --label repo-dispatch --state open --search "no:assignee" (or similar "not yet picked up" predicate). Parse the YAML frontmatter out of the issue body. The "handled" marker becomes an issue-side state change (assigning to a bot user, adding a dispatched:picked-up label, or just relying on the existence of a comment).
  • Ingest side (src/ingest/docs/repo_dispatch.rs). This module either deletes entirely or simplifies to a thin reader over labeled_issues_by_state("repo-dispatch", ...) (a surface that already exists for the autonomy metrics rollup). Health check moves from "does docs/repo-dispatch/ exist and parse" to "are there open repo-dispatch issues that look malformed."
  • Metrics side. recall_dispatch_metrics already derives from closed labeled issues. Mostly unchanged.

Tradeoffs:

  • For. One substrate instead of two; no filesystem queue artifact; gh CLI is the universal interface; dispatches become editable in the GitHub UI (which is sometimes useful for hand-tuning the prompt before pickup); cuts the planner's per-dispatch write cost from 2 round-trips (file + issue) to 1.
  • Against. Write-once is harder to enforce when the artifact is an editable issue body. The convention has to be "comment, don't edit" for status, which is already the recall-dispatch convention so this isn't a new discipline. GitHub issue body cap is 65k chars; some prompts are kilobytes but well under that ceiling. Searching is gh-search-shaped (server-side) rather than grep -r docs/repo-dispatch/ (filesystem); that's probably a net win for cross-repo planning.
  • Migration. Existing docs/repo-dispatch/*.md files keep ingesting until they're cleared by their corresponding closed tracking issues, then the ingest module retires. Or do a one-shot conversion that walks existing files, posts their bodies as comments on the matching tracking issues, and deletes the files. Either is fine; the latter is cleaner.

Out of scope. The tooling-autonomous-pickup Desktop "Start locally" card mechanism stays; only its source changes from on-disk queue to issue-list query.

Origin. Surfaced from a LUCA design conversation about how luca.ask should persist its Q&A. LUCA decided to skip the substrate-persisted shape entirely (everything LUCA writes will be skill-file changes, not markdown answer artifacts), but the same insight points at repo-dispatch's redundant artifact path.

_Originally filed by @coilysiren on 2026-05-19T08:10:24Z - [https://github.com/coilysiren/repo-recall/issues/200](https://github.com/coilysiren/repo-recall/issues/200)_ **Proposal.** Stop writing the per-dispatch markdown artifact at `docs/repo-dispatch/<slug>.md`. Put all the frontmatter + prompt body directly into the tracking GitHub issue. One substrate, not two. **Why this fits the existing model.** The substrate-hygiene rule in `recall-dispatch` SKILL.md already says: "No new state in repo-recall's local DB. Dispatch outcomes get derived from closed issues plus their commits." The markdown file is the one piece of dispatch state that isn't in GitHub. It already has a 1:1 tracking issue. Moving the prompt body into the issue body makes the substrate uniform and lets every consumer (planner, pickup, ingest, metrics) read one surface. **What changes:** - **Emitter side (`recall-dispatch`).** Stop writing `docs/repo-dispatch/<slug>.md`. Create the tracking issue with `label: repo-dispatch`, title = the dispatch slug (or its description), body = the existing markdown (frontmatter as a fenced YAML block at the top, prompt verbatim below). Skip the file system entirely. - **Pickup side (`tooling-autonomous-pickup`).** Instead of scanning `~/.repo-recall/dispatch/<repo>/*.md` and writing `.handled` sidecars, scan `gh issue list --label repo-dispatch --state open --search "no:assignee"` (or similar "not yet picked up" predicate). Parse the YAML frontmatter out of the issue body. The "handled" marker becomes an issue-side state change (assigning to a bot user, adding a `dispatched:picked-up` label, or just relying on the existence of a comment). - **Ingest side (`src/ingest/docs/repo_dispatch.rs`).** This module either deletes entirely or simplifies to a thin reader over `labeled_issues_by_state("repo-dispatch", ...)` (a surface that already exists for the autonomy metrics rollup). Health check moves from "does `docs/repo-dispatch/` exist and parse" to "are there open repo-dispatch issues that look malformed." - **Metrics side.** `recall_dispatch_metrics` already derives from closed labeled issues. Mostly unchanged. **Tradeoffs:** - **For.** One substrate instead of two; no filesystem queue artifact; gh CLI is the universal interface; dispatches become editable in the GitHub UI (which is sometimes useful for hand-tuning the prompt before pickup); cuts the planner's per-dispatch write cost from 2 round-trips (file + issue) to 1. - **Against.** Write-once is harder to enforce when the artifact is an editable issue body. The convention has to be "comment, don't edit" for status, which is already the recall-dispatch convention so this isn't a new discipline. GitHub issue body cap is 65k chars; some prompts are kilobytes but well under that ceiling. Searching is gh-search-shaped (server-side) rather than `grep -r docs/repo-dispatch/` (filesystem); that's probably a net win for cross-repo planning. - **Migration.** Existing `docs/repo-dispatch/*.md` files keep ingesting until they're cleared by their corresponding closed tracking issues, then the ingest module retires. Or do a one-shot conversion that walks existing files, posts their bodies as comments on the matching tracking issues, and deletes the files. Either is fine; the latter is cleaner. **Out of scope.** The `tooling-autonomous-pickup` Desktop "Start locally" card mechanism stays; only its source changes from on-disk queue to issue-list query. **Origin.** Surfaced from a LUCA design conversation about how `luca.ask` should persist its Q&A. LUCA decided to skip the substrate-persisted shape entirely (everything LUCA writes will be skill-file changes, not markdown answer artifacts), but the same insight points at repo-dispatch's redundant artifact path.
coilysiren added
P4
and removed
P3
labels 2026-05-31 07:01:16 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/repo-recall#28
No description provided.