work-items:work — work_dispatch_concurrency_cap / work_cycle_batch_cap are documented but not wired to any enforcement mechanism

[kyle-sexton]

Deferred from PR #563 review (Codex P2 + claude[bot] findings). /work-items:work Step 5 (SKILL.md:147) states desired values for two new userConfig scalars but connects neither to an execution mechanism. No edit confined to work/SKILL.md can make the assertions true — wiring requires changes to the delegated skill / driving loop — so this was deferred rather than asserted falsely in the PR.

work_dispatch_concurrency_cap

• SKILL.md:147 says "The maximum concurrent dispatch waves is \${user_config.work_dispatch_concurrency_cap}."
• But dispatch mechanics are owned by /implementation:implement-dispatch, which hardcodes "Cap concurrent dispatch waves at 3–5 workers" (implement-dispatch SKILL.md:17) and reads no userConfig. Nothing passes the work-skill value in as a parameter.
• Result: setting work_dispatch_concurrency_cap: 1 does not constrain anything — implement-dispatch still uses its internal 3–5.
• Fix options: (A) give /implementation:implement-dispatch a wave-cap parameter and have work pass the config value through; or (B) keep it a separate work-level cap and specify an enforcement point. The plugin.json description currently says it "mirrors" the implement-dispatch cap (suggesting B) while SKILL.md prose reads like A — the ambiguity is itself part of the gap.

work_cycle_batch_cap

• SKILL.md:147 says the batch cap "bounds one autonomous CYCLE" and that "Wakeup scheduling and the next-cycle delay are owned by the driving loop (/loop)."
• work itself selects and executes exactly one item per invocation and counts nothing; /loop is the external harness loop and has no knowledge of this plugin's userConfig key. A repo-wide grep finds no consumer of work_cycle_batch_cap outside the work-items plugin's own docs.
• Result: the batch cap is enforced nowhere. Needs either an in-skill batch counter with a cycle-end signal, or an explicit, real integration point that reads the key.

Acceptance

Either wire both caps to a real enforcement mechanism (parameter pass-through / batch counter) or, if they are intentionally advisory, state that unambiguously in the manifest + SKILL.md and remove language implying they constrain execution.

Filed by PR #563 review-response (babysit). Source threads: Codex P2 inline + claude[bot] PR-review comments on #563.

[kyle-sexton]

This was generated by AI during triage.

Triage — T3, needs-human, wayfind: design.

Genuine cross-skill enforcement-mechanism decision, not a single clear default: work_dispatch_concurrency_cap needs either (A) /implementation:implement-dispatch gaining a wave-cap parameter fed from work's config, or (B) staying a separate, differently-enforced cap — and the manifest description ("mirrors" the implement-dispatch cap) and the SKILL.md prose point at different answers, which is itself part of the gap. work_cycle_batch_cap similarly needs either a real in-skill batch counter or an explicit, honest downgrade to "advisory only." Both require a maintainer call on whether these configs are meant to bind sibling-skill behavior or are aspirational. Related to #572 (same source PR #563 review, same root cause, distinct specific gap).