Skip to content

Commit 7c409f0

Browse files
os-zhuangclaude
andauthored
docs(adr-0040): §5 build-scope rule — phased module decomposition + perception rule (#1757)
Records the scope-guard design shipped in cloud#242: soft design-time SCALE rule in propose_blueprint, hard apply-time cap (blueprint_too_large) with one per-context limit as the plan-entitlement read point, and the advice-vs-refusal perception rule for how limits surface to users. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
1 parent 4091c0e commit 7c409f0

1 file changed

Lines changed: 11 additions & 0 deletions

File tree

docs/adr/0040-unified-assistant-and-agent-binding.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,6 +89,17 @@ Today `chatWithTools` offers the **whole tool registry** to every agent; skills
8989
- Until then, a "read-only analyst" custom agent is a *persona*, not a *boundary* — documented as such wherever custom agents are exposed.
9090
- This incident is also why scoping matters beyond security: the Data Assistant failed precisely because it could reach tools whose disciplines it didn't carry.
9191

92+
### 5. Build-scope rule — oversized goals decompose into phased modules
93+
94+
A "build me a whole ERP, hundreds of tables" goal must not become one mass-generated blueprint: it is unreviewable in the blueprint-confirm step (ADR-0033's safety valve), unbuildable inside the agent's per-turn runtime budget, and design coherence collapses at that scale. The platform's answer is **consultative decomposition**, in two layers sharing one limit:
95+
96+
- **Soft (design-time)**`propose_blueprint` carries a SCALE rule: a single blueprint never exceeds the per-build object cap (aim ≤10). Larger goals blueprint ONLY the core module (smallest object set with end-to-end value); the remaining modules are emitted as a phased roadmap in `assumptions`. Later phases are ordinary follow-up blueprints in the same environment, referencing earlier objects via lookups.
97+
- **Hard (apply-time)**`apply_blueprint` rejects an oversized blueprint **before staging anything** (`code: 'blueprint_too_large'`), returning the same decomposition guidance so the agent re-proposes instead of retrying. The cap defaults to 20 and is read from one per-context limit (`BlueprintToolContext.limits.maxBlueprintObjects`) — the designated read point for plan-tier entitlements (a free tier is the same code path with a smaller N and the upsell moment built into the roadmap).
98+
99+
**Perception rule**: limits that can manifest as *advice* stay invisible — the agent frames phasing as professional delivery methodology, never as a system or plan limitation. Limits that can only manifest as *refusal* (quota exhausted) must be stated honestly at the moment of impact, with a recovery path. An invisible wall the user can hit reads as "the AI is broken," which is the most expensive failure mode.
100+
101+
Verified by the L5 suite's `golden_erp_scope` case: an "entire ERP" prompt must yield a bounded core-module build plus a roadmap, never dozens of staged objects.
102+
92103
## Non-goals
93104

94105
- **Not** removing the multi-agent system — binding, API selection, eval, and channels all need it.

0 commit comments

Comments
 (0)