Phase 6 — Output paths #6

Closed
opened 2026-07-29 16:38:02 +03:00 by oleks · 2 comments
Owner

Per design/tasks.md Phase 6. Blocked by Phase 4 calibration passing (closed).

  • 6.1 references/issue-template.md per design/plan.md §10
  • 6.2 anxious:issuer delegation path — plugin holds no Gitea credentials, calls no Gitea tool; token-offload label passed as required, four-axis taxonomy left to issuer
  • 6.3 Idempotency (FR-6.3) — verified against LIVE Gitea with a scratch probe issue (created + closed within the session, confirmed cleaned up). Real finding: search_issues/list_issues don't return the body field, so identity requires a 3-step flow (label-scoped listing ∪ full-text query → per-issue body/comment fetch → local literal match). --existing is 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.
  • 6.4 Graceful filing: unavailable — tested against a real repo-less plugin (third-party/baoyu-design, github.com-only remote)
  • 6.5 (merged into 6.3/6.4 test coverage)
  • 6.6 skills/offload-audit/SKILL.md and commands/offload-audit.md

Implemented in f02ef23, 4d6f6f7, c6c23c4. No issue was filed to any real target repo — confirmed independently (searched for any token-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: 5bdc984 mixed 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.

Per design/tasks.md Phase 6. Blocked by Phase 4 calibration passing (closed). - [x] 6.1 `references/issue-template.md` per design/plan.md §10 - [x] 6.2 `anxious:issuer` delegation path — plugin holds no Gitea credentials, calls no Gitea tool; `token-offload` label passed as required, four-axis taxonomy left to `issuer` - [x] 6.3 **Idempotency (FR-6.3)** — verified against LIVE Gitea with a scratch probe issue (created + closed within the session, confirmed cleaned up). Real finding: `search_issues`/`list_issues` don't return the `body` field, so identity requires a 3-step flow (label-scoped listing ∪ full-text query → per-issue body/comment fetch → local literal match). `--existing` is 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. - [x] 6.4 Graceful `filing: unavailable` — tested against a real repo-less plugin (`third-party/baoyu-design`, github.com-only remote) - [x] 6.5 (merged into 6.3/6.4 test coverage) - [x] 6.6 `skills/offload-audit/SKILL.md` and `commands/offload-audit.md` Implemented in `f02ef23`, `4d6f6f7`, `c6c23c4`. **No issue was filed to any real target repo** — confirmed independently (searched for any `token-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: `5bdc984` mixed 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.
oleks added this to the v0.1.0 milestone 2026-07-29 16:38:02 +03:00
oleks added a new dependency 2026-07-29 16:38:29 +03:00
oleks added a new dependency 2026-07-29 16:38:31 +03:00
Author
Owner

Phase 6 — output paths: built and pushed

design/tasks.md 6.1–6.6 checked off. Commits 5bdc984 (see note below) and f02ef23. Nothing was filed to any real target repo — that stays gated behind Phase 7 / S4 and user sign-off.

What landed

Path What it is
references/issue-template.md The issue-body contract per plan §10, plus the verified marker-search mechanics. Same "heading + one fenced block" parser convention as signals-catalog.md.
bin/filing-plan Decides file / comment / skip per candidate and renders both bodies. Two subcommands: queries (resolve repo, emit the searches) and plan (consume their results).
skills/offload-audit/SKILL.md The main procedure: resolve → inventory → scan → rubric → classify → path A → path B → report.
commands/offload-audit.md /offload-audit <plugin> [--days N].
tests/filing.test.sh 40 assertions; wired in via run-all.sh's glob.
agents/offload-analyst.md Replaced the stale "Phase 6 — not yet built / file nothing" section.

FR-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_issues does full-text match body content, including inside an HTML comment — a query for a string appearing only in the body returned the issue.
  • But neither search_issues nor list_issues returns the body field. Metadata only. A marker match therefore cannot be made from a search result at all — the body needs a per-issue issue_read(method="get"), and comments issue_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 in filing-plan. The search engine never decides identity.

Two consequences baked in:

  • filing-plan plan requires --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.
  • Matching covers the body and every comment, so an issue keeps its identity even if a human rewrites the body, as long as one update comment survives.

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_id correctly 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 is github.com. plugin-inventory resolves it; filing-plan reports filing: unavailable with 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 on git.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-plan renders the body and proposes a title; issuer owns repo, final title, milestone, and the four-axis taxonomy labels. Only token-offload is 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.md regeneration, and the page list. offload-audit calls audit-snapshot write --issue-map (path A runs first, so the summary records real issue numbers) then audit-snapshot pages, and delegates the wiki writes to cluster:gitea-agent.

One open seam: filing: unavailable can't reach the wiki page today, because notes in build_snapshot is derived internally and not injectable. Requested a repeatable --note flag from the Phase 5 agent. Until then the reason is recorded in filing-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.sh green end to end (inventory, scan, classify incl. both calibration gates, snapshot, filing). shellcheck clean on tests/filing.test.sh. bin/filing-plan carries 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.

## Phase 6 — output paths: built and pushed `design/tasks.md` 6.1–6.6 checked off. Commits `5bdc984` (see note below) and `f02ef23`. Nothing was filed to any real target repo — that stays gated behind Phase 7 / S4 and user sign-off. ### What landed | Path | What it is | |---|---| | `references/issue-template.md` | The issue-body contract per plan §10, plus the verified marker-search mechanics. Same "heading + one fenced block" parser convention as `signals-catalog.md`. | | `bin/filing-plan` | Decides `file` / `comment` / `skip` per candidate and renders both bodies. Two subcommands: `queries` (resolve repo, emit the searches) and `plan` (consume their results). | | `skills/offload-audit/SKILL.md` | The main procedure: resolve → inventory → scan → rubric → classify → path A → path B → report. | | `commands/offload-audit.md` | `/offload-audit <plugin> [--days N]`. | | `tests/filing.test.sh` | 40 assertions; wired in via `run-all.sh`'s glob. | | `agents/offload-analyst.md` | Replaced the stale "Phase 6 — not yet built / file nothing" section. | ### FR-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_issues` does full-text match body content**, including inside an HTML comment — a query for a string appearing only in the body returned the issue. - **But neither `search_issues` nor `list_issues` returns the `body` field.** Metadata only. A marker match therefore cannot be made from a search result at all — the body needs a per-issue `issue_read(method="get")`, and comments `issue_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** in `filing-plan`. The search engine never decides identity. Two consequences baked in: - `filing-plan plan` **requires** `--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. - Matching covers the body **and every comment**, so an issue keeps its identity even if a human rewrites the body, as long as one update comment survives. 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_id` correctly 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 is `github.com`. `plugin-inventory` resolves it; `filing-plan` reports `filing: unavailable` with 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 on `git.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-plan` renders the body and proposes a title; `issuer` owns repo, final title, milestone, and the four-axis taxonomy labels. Only `token-offload` is 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.md` regeneration, and the page list. `offload-audit` calls `audit-snapshot write --issue-map` (path A runs first, so the summary records real issue numbers) then `audit-snapshot pages`, and delegates the wiki writes to `cluster:gitea-agent`. One open seam: `filing: unavailable` can't reach the wiki page today, because `notes` in `build_snapshot` is derived internally and not injectable. Requested a repeatable `--note` flag from the Phase 5 agent. Until then the reason is recorded in `filing-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.sh` green end to end (inventory, scan, classify incl. both calibration gates, snapshot, filing). `shellcheck` clean on `tests/filing.test.sh`. `bin/filing-plan` carries the executable bit. Leaving this issue open for review. <sub>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.</sub>
Author
Owner

Follow-up: the one open seam from the Phase 6 comment above is closed.

The Phase 5 agent shipped a repeatable --note on audit-snapshot write (4d6f6f7), so FR-6.4's reason now reaches Audits/<target>/<YYYY-MM-DD> under ## Notes instead of living only in filing-plan's output. skills/offload-audit/SKILL.md updated in c6c23c4 to require it rather than treat it as conditional:

--note "filing: unavailable — <the reason from filing-plan, verbatim>"

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_write create/update take the page title, but delete takes the URL-decoded sub_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.

Follow-up: the one open seam from the Phase 6 comment above is closed. The Phase 5 agent shipped a repeatable `--note` on `audit-snapshot write` (`4d6f6f7`), so FR-6.4's reason now reaches `Audits/<target>/<YYYY-MM-DD>` under `## Notes` instead of living only in `filing-plan`'s output. `skills/offload-audit/SKILL.md` updated in `c6c23c4` to require it rather than treat it as conditional: ```text --note "filing: unavailable — <the reason from filing-plan, verbatim>" ``` 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_write` `create`/`update` take the page **title**, but `delete` takes the URL-decoded `sub_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.
oleks closed this issue 2026-07-29 17:58:26 +03:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Blocks
#7 Phase 7 — Acceptance
kotkan/claude-plugin-inference-arbitrage
Depends on
#4 Phase 4 — Rubric and classification
kotkan/claude-plugin-inference-arbitrage
Reference: kotkan/claude-plugin-inference-arbitrage#6