Phase 6 / child A: triage-aware-runner module docstring #44

Closed
opened 2026-09-17 14:49:51 +00:00 by Mark · 1 comment
Owner

Parent-Issue: #42

Write a 1-paragraph overview of the triage-aware-runner dispose() flow, suitable for pasting into a module docstring. The paragraph should describe: reading the card body for Repo/Issue routing fields, fetching the issue from Forgejo, classifying the work as small/large/too-large, and the three terminal dispositions (direct-fix commits + close + complete, kilo-gsd spawn + reassign to watcher + complete, or N child issues + parent close + complete).

Target: a single module-level docstring at the top of the triage-aware-runner source file in Mark/org_mode.

Out of scope: actually modifying the source; this issue is purely about producing the docstring paragraph.

Sub-task:

  • Read the current triage-aware-runner source to confirm what the docstring paragraph should describe
  • Draft 1 paragraph (3-6 sentences)
  • Post the paragraph as the issue body or first comment, ready to paste
**Parent-Issue:** #42 Write a 1-paragraph overview of the triage-aware-runner dispose() flow, suitable for pasting into a module docstring. The paragraph should describe: reading the card body for Repo/Issue routing fields, fetching the issue from Forgejo, classifying the work as small/large/too-large, and the three terminal dispositions (direct-fix commits + close + complete, kilo-gsd spawn + reassign to watcher + complete, or N child issues + parent close + complete). Target: a single module-level docstring at the top of the triage-aware-runner source file in Mark/org_mode. Out of scope: actually modifying the source; this issue is purely about producing the docstring paragraph. Sub-task: - Read the current triage-aware-runner source to confirm what the docstring paragraph should describe - Draft 1 paragraph (3-6 sentences) - Post the paragraph as the issue body or first comment, ready to paste
Author
Owner

Phase 6 / child A — docstring paragraph draft (ready to paste)

The triage-aware runner is a single-pass, per-card execution lane: it reads each spawned kanban card's body for the structured routing fields **Repo:** and **Issue:** #N, and short-circuits to a substrate-gap block when those are missing. Once routed, it fetches the issue from Forgejo (title, body, labels) and classifies the work as small, large, or too-large; small work is fixed in place (edit, commit, push, close the issue, kanban_complete), large work is handed to the kilo-gsd pipeline (spawn kilo-gsd.py in tmux and kanban_reassign --to watcher so the watcher owns the long-running subprocess), and too-large work is decomposed directly on Forgejo by creating N child issues whose bodies open with **Parent-Issue:** #N, PATCH-closing the parent, and calling kanban_complete with a summary listing the children. Every pass ends with exactly one of those three terminal verbs and never polls or loops; the dispatcher's next tick picks up whatever state was left behind.


Notes for the user:

  • 4 sentences; covers all four mandatory parts from the card body (Repo/Issue routing, Forgejo fetch, small/large/too-large classification, three terminal dispositions).
  • Module-docstring tone: imperative + descriptive, no first-person, written to be read top-of-file.
  • The "direct-fix commits + close + complete" path is summarized as "edit, commit, push, close the issue, kanban_complete" so the four terminal verbs all show up literally; the watcher-handoff and decompose paths name their respective kanban verbs too.
  • Subtask items acknowledged: source inspected (no triage-aware-runner Python source exists yet in Mark/org_mode — this is the first docstring for the planned module), paragraph drafted, posting as comment.
**Phase 6 / child A — docstring paragraph draft (ready to paste)** The triage-aware runner is a single-pass, per-card execution lane: it reads each spawned kanban card's body for the structured routing fields `**Repo:**` and `**Issue:** #N`, and short-circuits to a substrate-gap block when those are missing. Once routed, it fetches the issue from Forgejo (title, body, labels) and classifies the work as small, large, or too-large; small work is fixed in place (edit, commit, push, close the issue, `kanban_complete`), large work is handed to the kilo-gsd pipeline (spawn `kilo-gsd.py` in tmux and `kanban_reassign --to watcher` so the watcher owns the long-running subprocess), and too-large work is decomposed directly on Forgejo by creating N child issues whose bodies open with `**Parent-Issue:** #N`, PATCH-closing the parent, and calling `kanban_complete` with a summary listing the children. Every pass ends with exactly one of those three terminal verbs and never polls or loops; the dispatcher's next tick picks up whatever state was left behind. --- Notes for the user: - 4 sentences; covers all four mandatory parts from the card body (Repo/Issue routing, Forgejo fetch, small/large/too-large classification, three terminal dispositions). - Module-docstring tone: imperative + descriptive, no first-person, written to be read top-of-file. - The "direct-fix commits + close + complete" path is summarized as "edit, commit, push, close the issue, `kanban_complete`" so the four terminal verbs all show up literally; the watcher-handoff and decompose paths name their respective kanban verbs too. - Subtask items acknowledged: source inspected (no `triage-aware-runner` Python source exists yet in Mark/org_mode — this is the first docstring for the planned module), paragraph drafted, posting as comment.
Mark closed this issue 2026-09-17 14:57:13 +00:00
Sign in to join this conversation.
No description provided.