Extract the reusable helper packages from ward (cli-guard-first half of ward#269) #166

New issue

Closed

opened 2026-06-25 09:22:23 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-06-25 09:22:23 +00:00

Member

The cli-guard-first half of ward#269's cross-repo extraction. A headless container cannot span both repos, so this lands the packages in cli-guard first, tags a release, and ward#269 becomes the follow-up that bumps the pin and deletes the ward-side copies.

Land in cli-guard (exported, importable):

pkg/scan - the junk-scan helper
pkg/attribution - attribution
pkg/flock - flock
pkg/version - semver
the cli/hook registry (hook tables) + settings-installer
owner-trust
an exported ParseIssueRef (issue-ref)

Then tag a cli-guard release so ward can pin it.

Sequencing: ward#269 waits on this landing + the release tag, then bumps the pin and removes the copies. Both sides are also gated on the headless-container dispatch fix (ward#311 / #321 / #322) - cli-guard headless dispatch is currently broken (cli-guard#79 died on it), so this likely needs a hand-run or the fix first. Origin: ward#269 blocked on the cross-repo path; path B (cli-guard-first split) chosen.

The cli-guard-first half of ward#269's cross-repo extraction. A headless container cannot span both repos, so this lands the packages **in cli-guard first**, tags a release, and ward#269 becomes the follow-up that bumps the pin and deletes the ward-side copies. **Land in cli-guard** (exported, importable): - `pkg/scan` - the junk-scan helper - `pkg/attribution` - attribution - `pkg/flock` - flock - `pkg/version` - semver - the `cli/hook` registry (hook tables) + settings-installer - owner-trust - an exported `ParseIssueRef` (issue-ref) Then **tag a cli-guard release** so ward can pin it. **Sequencing**: ward#269 waits on this landing + the release tag, then bumps the pin and removes the copies. Both sides are also gated on the headless-container dispatch fix (ward#311 / #321 / #322) - cli-guard headless dispatch is currently broken (cli-guard#79 died on it), so this likely needs a hand-run or the fix first. Origin: ward#269 blocked on the cross-repo path; path B (cli-guard-first split) chosen.

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-06-25 09:22:47 +00:00

Extract the small reusable helpers to cli-guard (junk-scan, settings-installer, hook tables, attribution, flock, semver, owner-trust, issue-ref) #269

coilyco-ops commented

2026-06-25 10:22:55 +00:00

Author

Member

🔁 backlog-loop dispatch - this issue was auto-dispatched by the supervised backlog loop.

When you finish, your final issue comment must start with exactly one of:

WARD-OUTCOME: done - landed/merged, nothing more needed.
WARD-OUTCOME: blocked - <the specific decision or information you need from a human>
WARD-OUTCOME: failed - <why, briefly>

Put your candid retrospective on the line(s) below it. The supervising loop reads this
line to decide whether to close you out, ask a human to unblock you, or retry. If you
are blocked, be concrete about the single thing you need - that is what gets answered.

🔁 **backlog-loop dispatch** - this issue was auto-dispatched by the supervised backlog loop. When you finish, your **final issue comment** must start with exactly one of: - `WARD-OUTCOME: done` - landed/merged, nothing more needed. - `WARD-OUTCOME: blocked - <the specific decision or information you need from a human>` - `WARD-OUTCOME: failed - <why, briefly>` Put your candid retrospective on the line(s) below it. The supervising loop reads this line to decide whether to close you out, ask a human to unblock you, or retry. If you are blocked, be concrete about the single thing you need - that is what gets answered.

coilyco-ops commented

2026-06-25 10:22:58 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container ward-cli-guard-issue-166-claude-722137cd on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-06-25T10:22:58Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `ward-cli-guard-issue-166-claude-722137cd` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-06-25T10:22:58Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-06-25 10:47:54 +00:00

feat(helpers): extract reusable helper packages from ward

coilysiren closed this issue

2026-06-25 10:47:54 +00:00

coilysiren commented

2026-06-25 10:49:01 +00:00

Owner

WARD-OUTCOME: done

The six helper packages plus the hook registry/installer were straightforward to lift. The friction was all in the guardrails, not the Go.

Both inventory docs (FEATURES.md, features-detail.md) sit about 4 chars under the 4000-char doc cap by design, so every line I added overflowed. I split the detail into a new docs/ward-helpers.md and tightened existing prose to fit. The code-comments rule (contiguous blocks of 2 lines max after the package doc) then made me compress most function docstrings and push the nuance into the exempt package headers and that new doc. Neither was hard, just unexpected for what looked like a pure "add packages" task.

One judgment call worth flagging: ParseIssueRef and owner-trust already live inside cli/dispatch, but coupled to the Dispatcher/Config. I built standalone pkg/issueref and pkg/ownertrust as the free-function reusable homes rather than refactor dispatch, to keep the blast radius small. That leaves a transient duplication worth a follow-up (have dispatch delegate to these once the ward half of #269 lands).

Confidence is high on the helpers themselves. Every package ships tests and the full lint/vet/godoc/pre-commit suite is green. The only red tests in the tree are the pre-existing cli/sandbox seccomp/ptrace ones, which are environmental (no kernel caps in this container), not mine. The actual ward-side dedup, deleting ward's copies and importing these, is still pending its own run, since one headless container can't span both repos.

WARD-OUTCOME: done The six helper packages plus the hook registry/installer were straightforward to lift. The friction was all in the guardrails, not the Go. Both inventory docs (FEATURES.md, features-detail.md) sit about 4 chars under the 4000-char doc cap by design, so every line I added overflowed. I split the detail into a new docs/ward-helpers.md and tightened existing prose to fit. The code-comments rule (contiguous blocks of 2 lines max after the package doc) then made me compress most function docstrings and push the nuance into the exempt package headers and that new doc. Neither was hard, just unexpected for what looked like a pure "add packages" task. One judgment call worth flagging: ParseIssueRef and owner-trust already live inside cli/dispatch, but coupled to the Dispatcher/Config. I built standalone pkg/issueref and pkg/ownertrust as the free-function reusable homes rather than refactor dispatch, to keep the blast radius small. That leaves a transient duplication worth a follow-up (have dispatch delegate to these once the ward half of #269 lands). Confidence is high on the helpers themselves. Every package ships tests and the full lint/vet/godoc/pre-commit suite is green. The only red tests in the tree are the pre-existing cli/sandbox seccomp/ptrace ones, which are environmental (no kernel caps in this container), not mine. The actual ward-side dedup, deleting ward's copies and importing these, is still pending its own run, since one headless container can't span both repos.