Phase 6 / child A: triage-aware-runner module docstring #44
Labels
No labels
blocked:needs-decision
bug
chore
cron
design
in-progress
infra
milestone
module-o
needs-decompose
needs-research
ops-task
pm
quickfix
security/medium
triage-approved
vikunja
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/org_mode#44
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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 (spawnkilo-gsd.pyin tmux andkanban_reassign --to watcherso 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 callingkanban_completewith 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:
kanban_complete" so the four terminal verbs all show up literally; the watcher-handoff and decompose paths name their respective kanban verbs too.triage-aware-runnerPython source exists yet in Mark/org_mode — this is the first docstring for the planned module), paragraph drafted, posting as comment.