Phase 6 — Output paths #6
Notifications
Due Date
No due date set.
Blocks
Depends on
#7 Phase 7 — Acceptance
kotkan/claude-plugin-inference-arbitrage
#4 Phase 4 — Rubric and classification
kotkan/claude-plugin-inference-arbitrage
Reference: kotkan/claude-plugin-inference-arbitrage#6
Reference in New Issue
Block a user
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?
Per design/tasks.md Phase 6. Blocked by Phase 4 calibration passing (closed).
references/issue-template.mdper design/plan.md §10anxious:issuerdelegation path — plugin holds no Gitea credentials, calls no Gitea tool;token-offloadlabel passed as required, four-axis taxonomy left toissuersearch_issues/list_issuesdon't return thebodyfield, so identity requires a 3-step flow (label-scoped listing ∪ full-text query → per-issue body/comment fetch → local literal match).--existingis a mandatory flag — a skipped search can never silently mean "file it all." Double-run, marker-in-comment-only, and two-issues-same-marker edge cases all tested.filing: unavailable— tested against a real repo-less plugin (third-party/baoyu-design, github.com-only remote)skills/offload-audit/SKILL.mdandcommands/offload-audit.mdImplemented in
f02ef23,4d6f6f7,c6c23c4. No issue was filed to any real target repo — confirmed independently (searched for anytoken-offload-labeled issue anywhere; only the self-cleaned scratch probe exists, on this repo).bash tests/run-all.sh: 147 assertions, exit 0, shellcheck clean.Note:
5bdc984mixed Phase 5 and Phase 6 files due to a shared working tree during concurrent development — disclosed honestly in the issue comment; content verified correct, not rewritten to avoid racing the other agent.Phase 6 — output paths: built and pushed
design/tasks.md6.1–6.6 checked off. Commits5bdc984(see note below) andf02ef23. Nothing was filed to any real target repo — that stays gated behind Phase 7 / S4 and user sign-off.What landed
references/issue-template.mdsignals-catalog.md.bin/filing-planfile/comment/skipper candidate and renders both bodies. Two subcommands:queries(resolve repo, emit the searches) andplan(consume their results).skills/offload-audit/SKILL.mdcommands/offload-audit.md/offload-audit <plugin> [--days N].tests/filing.test.shrun-all.sh's glob.agents/offload-analyst.mdFR-6.3 idempotency — the marker search actually works, and the naive design did not
Verified against live Gitea with a scratch probe issue on this repo (
#9, created and closed within the session):search_issuesdoes full-text match body content, including inside an HTML comment — a query for a string appearing only in the body returned the issue.search_issuesnorlist_issuesreturns thebodyfield. Metadata only. A marker match therefore cannot be made from a search result at all — the body needs a per-issueissue_read(method="get"), and commentsissue_read(method="get_comments"). Both confirmed to return what's needed.So the documented flow is three steps, not one: label-scoped listing (authoritative, since every filed issue carries
token-offload) ∪ full-text query → per-issue body/comment fetch → local literal match infiling-plan. The search engine never decides identity.Two consequences baked in:
filing-plan planrequires--existing, even when empty. Defaulting to "nothing exists" turns a failed search into a duplicate-filing spree, which is the outcome FR-6.3 exists to prevent.The double-run test proves it the only way that means anything: run 1's actual rendered body is fed back as the tracker's state for run 2, which then produces a comment and files nothing. Run 3 strips the marker from the body, leaving it only in run 2's comment — still no duplicate. A different
candidate_idcorrectly does not match. Two issues carrying the same marker warn and take the lowest number.FR-6.4 degradation — tested against a real repo-less plugin
third-party/baoyu-design, whose only remote isgithub.com.plugin-inventoryresolves it;filing-planreportsfiling: unavailablewith the remote named in the reason, emits no queries, and marks the candidate skipped. Path B still runs. Repo resolution order is explicit flag → the target checkout's own remote → the workspace sibling checkout (needed because audits normally run against~/.claude/plugins/cache/..., which has no.git), and "writable" means the remote is ongit.oleks.space.Delegation (FR-6.1/6.2)
Unchanged and fixed:
offload-audit → Agent(anxious:issuer-agent) → cluster:gitea-agent → Gitea. This plugin holds no Gitea credentials and the artifact calls no Gitea tool.filing-planrenders the body and proposes a title;issuerowns repo, final title, milestone, and the four-axis taxonomy labels. Onlytoken-offloadis passed as required, with colour and description for creation-on-first-use. Filing is implicit — the skill states it does not ask permission for a candidate that cleared the gate, and equally never files one that did not.Path B seam with Phase 5
No duplication:
bin/audit-snapshot(Phase 5) owns rendering,Latest.mdregeneration, and the page list.offload-auditcallsaudit-snapshot write --issue-map(path A runs first, so the summary records real issue numbers) thenaudit-snapshot pages, and delegates the wiki writes tocluster:gitea-agent.One open seam:
filing: unavailablecan't reach the wiki page today, becausenotesinbuild_snapshotis derived internally and not injectable. Requested a repeatable--noteflag from the Phase 5 agent. Until then the reason is recorded infiling-plan's output and in the report to the user, which satisfies FR-6.4's substance but not its wiki half.Verification
bash tests/run-all.shgreen end to end (inventory, scan, classify incl. both calibration gates, snapshot, filing).shellcheckclean ontests/filing.test.sh.bin/filing-plancarries the executable bit.Leaving this issue open for review.
Note on
5bdc984: the Phase 5 agent and I shared one working tree, and my staged Phase 6 files were swept into its commit, whose message reads "Fix markdown lint in the Phase 5 docs". The content is correct; I did not rewrite that commit because doing so would have raced a concurrently-running agent.Follow-up: the one open seam from the Phase 6 comment above is closed.
The Phase 5 agent shipped a repeatable
--noteonaudit-snapshot write(4d6f6f7), so FR-6.4's reason now reachesAudits/<target>/<YYYY-MM-DD>under## Notesinstead of living only infiling-plan's output.skills/offload-audit/SKILL.mdupdated inc6c23c4to require it rather than treat it as conditional:Same mechanism is now also called for on a failed marker search or a plan that could not be fully executed — outcomes the snapshot scripts make no Gitea calls to see.
Also recorded in the skill, from the Phase 5 agent's live verification:
wiki_writecreate/updatetake the page title, butdeletetakes the URL-decodedsub_url(Data/<target>/snapshots.jsonl.-) — deleting by title 404s.Full suite still green. Phase 6 has no open items on my side; still leaving this issue for your review.