gate:ask reports why the form cap forced a wait - #317
Conversation
A caller whose question busts the in-pane form's 4-option cap used to get a bare wait with no reason, which is how option-folding survived in every wrapper skill. When the pane could have presented a form, the response now carries formCapExceeded naming each over-cap question plus the structural remedy, on the CLI (stdout field + stderr line, like contextOmitted) and the gate_ask tool alike; the tool description teaches the cap up front. Never a refusal: an over-cap wait gate stays legitimate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe ChangesGate Form-Cap Advisories
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~12 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant MCPClient
participant GateHandler
participant GateCLI
MCPClient->>GateHandler: send gate:ask questions
GateHandler->>GateHandler: detect options above four
GateHandler-->>MCPClient: return formCapExceeded and formCapAdvisory
GateHandler-->>GateCLI: return gate response
GateCLI->>GateCLI: print affected questions and advisory
Merge Risk: ⚪ Minimal · up to The form-cap diagnostics are consistently represented across the handler, client contract, CLI, MCP guidance, and targeted tests. No merge-blocking issue remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
A caller whose question exceeds the in-pane form's 4-option cap used to get a bare "wait" back with no reason; that silence is why navigation-verb folding survived across the wrapper skills (three live specimens today: 5- and 6-option questions degrading gates to the wait queue).
When the pane and session would have supported a form and one or more questions exceed the cap, the gate:ask response now carries formCapExceeded ([{question, options}]) and formCapAdvisory naming the structural remedy, through both surfaces: the CLI prints the fields on stdout and one advisory line on stderr (mirroring contextOmitted), and the gate_ask MCP tool returns the same fields with the cap taught in its description. A pane-less ask waits for its own reason and carries no advisory. Never a refusal: an over-cap wait gate is legitimate (remote cards render any option count).
Verified: handler + CLI + MCP suites and the gate-ask e2e file green; rt-client dist rebuilt.
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
waitstatus with guidance for handling the choices.Documentation
gate_askguidance to describe the four-option in-pane limit and recommended question formats.