coilyco-flight-deck/ward

Archived

Watch

Add a first class guided setup command #426

Closed

opened 2026-07-01 20:22:07 +00:00 by coilysiren · 3 comments

coilysiren commented

2026-07-01 20:22:07 +00:00

Owner

warded setup just to be cute

helps you generate KDL, etc etc

`warded setup` just to be cute helps you generate KDL, etc etc

coilyco-ops added this to the ward launch milestone

2026-07-01 23:57:08 +00:00

coilyco-ops added the

autonomy

headless

priority

labels

2026-07-01 23:57:08 +00:00

coilyco-ops commented

2026-07-01 23:59:31 +00:00

Owner

Pulled into the launch milestone during triage. Scope per decided direction: warded setup generates .ward/ward.yaml (commands inferred from Makefile targets) + a security: block scaffold, then runs doctor; NO guardfile authoring (per #455/#437 - ward.yaml is the adoption contract). Agent proposes UX in the PR. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops commented

2026-07-02 03:00:39 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-426 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T03:00:36Z). 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 `engineer-claude-ward-426` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T03:00:36Z). 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-07-02 03:16:59 +00:00

feat(setup): add `ward setup` guided onboarding verb

coilysiren closed this issue

2026-07-02 03:16:59 +00:00

coilysiren commented

2026-07-02 03:17:29 +00:00

Author

Owner

WARD-OUTCOME: done - ward setup (warded setup) scaffolds .ward/ward.yaml from Makefile targets + a commented security block, then runs doctor; landed on main.

The triage comment did most of the hard thinking for me - scoping this to ward.yaml generation (no guardfile authoring) turned a fuzzy "generate KDL, etc etc" into something crisp. The nicest part was that the allowlist drift-guard already defines exactly what a valid verb looks like (run: make <name> + a ## help description that matches), so generating straight from the Makefile means doctor passes on the first run by construction - the feature and its own validator fit together for free.

Two things fought back, both mundane. The warded public face rewrites to ward agent, so I carved setup out of that shim to honor the literal warded setup spelling - small, but it does poke a hole in the "warded IS ward agent" contract, so worth a second opinion. And FEATURES.md was sitting 2 chars under its 4000-char doc-layout cap after the merge, so adding one inventory line meant reclaiming space by tightening the (redundant) ward agent entry. That cap is going to bite the next person too; splitting FEATURES.md is probably a real follow-up.

Fairly confident in the result: unit tests cover the Makefile parse (order, skips, dupes), the YAML round-trip, the overwrite guard, and doctor-on-generated-config end to end, plus I drove it by hand against synthetic Makefiles. One rough edge I left deliberately: the security block ships commented-out so a fresh scaffold stays green under doctor rather than failing on host sudo/path posture - a judgment call worth a glance. I also noticed a pre-existing drift in this repo's own ward.yaml (the install description no longer matches the Makefile) - untouched by this change, but someone should file it.

WARD-OUTCOME: done - `ward setup` (`warded setup`) scaffolds `.ward/ward.yaml` from Makefile targets + a commented security block, then runs doctor; landed on main. The triage comment did most of the hard thinking for me - scoping this to ward.yaml generation (no guardfile authoring) turned a fuzzy "generate KDL, etc etc" into something crisp. The nicest part was that the allowlist drift-guard already defines exactly what a valid verb looks like (`run: make <name>` + a `## ` help description that matches), so generating straight from the Makefile means doctor passes on the first run by construction - the feature and its own validator fit together for free. Two things fought back, both mundane. The `warded` public face rewrites to `ward agent`, so I carved `setup` out of that shim to honor the literal `warded setup` spelling - small, but it does poke a hole in the "warded IS ward agent" contract, so worth a second opinion. And FEATURES.md was sitting 2 chars under its 4000-char doc-layout cap after the merge, so adding one inventory line meant reclaiming space by tightening the (redundant) `ward agent` entry. That cap is going to bite the next person too; splitting FEATURES.md is probably a real follow-up. Fairly confident in the result: unit tests cover the Makefile parse (order, skips, dupes), the YAML round-trip, the overwrite guard, and doctor-on-generated-config end to end, plus I drove it by hand against synthetic Makefiles. One rough edge I left deliberately: the security block ships commented-out so a fresh scaffold stays green under doctor rather than failing on host sudo/path posture - a judgment call worth a glance. I also noticed a pre-existing drift in this repo's own ward.yaml (the `install` description no longer matches the Makefile) - untouched by this change, but someone should file it.

Commenting is not possible because the repository is archived.

No milestone

No project

No assignees

2 participants

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#426

No description provided.

Rows
Columns