Repository navigation
design: L1.12.b — Fn-scope + (C2) say 'registered canonical-home' + extend concept_home producer to type-scope (cursor APPROVE_WITH_COMMENTS post-merge reconcile) - #3487
Merged
briansrls merged 1 commit intoMay 21, 2026
Conversation
…xtend concept_home producer to type-scope (cursor APPROVE_WITH_COMMENTS reconcile) cursor APPROVE_WITH_COMMENTS on PR #3479 raised one valid non-blocking finding plus one exploratory: [main finding, non-blocking] When I propagated 'registered canonical- home' through the trigger + Kills in the operator-tightening pass, I missed the Fn-scope bullet (:1156-1163) and the (C2) text. Internal inconsistency — Trigger C says canonical-home (concept-home index); Fn-scope and (C2) said 'std/' fn / 'std/-registered' type. Worker following Fn-scope literally would miss the count_named_bind (C1) case against the non-std/ canonical home src/v3/lenses/named_function_count.dag. Fix: - Fn-scope bullet updated to say 'matches an existing registered canonical-home fn' with explicit pointer to count_named_bind as the precedent of a non-std/ canonical home. - (C2) text updated to require FoldRegistryEntry.carrier points at a 'registered canonical-home type' (same canonical-home discipline as type-scope and (C1) fn-scope; std/ default, non-std/ qualifies when the concept-home index says so). [exploratory] v4.lens.concept_home is defined as Map<FnId, File> only — type-scope canonical-home would need an extended index when non-std/ canonical types matter beyond the fn example. Type-scope (C1) was relying on a concept-home authority the producer stage didn't actually provide. Fix: - v4.lens.concept_home's produces signature broadened to Map<DeclId, File> where DeclId = FnId | TypeId. Same producer stage, broader output — no new derived stage; the type-scope canonical-home authority lives in the same record as fn-scope. Facts Flow Forward / P2 preserved (one producer, multiple consumers). - Explicit prose explaining why the broadening: L1.12.b's type-scope (C1) needs the same canonical-home resolution fn-scope (C1) does; one mechanism for both. - 'reusable by' updated to call out the dual consumer pattern (L1.8 fn-home class, L1.12.b fn + type canonical-home authority). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
briansrls
deleted the
session/smart-lynx-142-l1-12-b-canonical-home-reconcile
branch
June 1, 2026 18:43
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cursor's APPROVE_WITH_COMMENTS on PR #3479 raised one valid finding + one exploratory observation that landed AFTER PR #3479 was squash-merged. This is the follow-up PR with the reconcile fix applied to main.
[Main, non-blocking] When I propagated "registered canonical-home" through the L1.12.b trigger + Kills in the operator-tightening pass, I missed the Fn-scope bullet (
docs/design-dissolution-lens.md:1304) and the (C2) text. Internal inconsistency — Trigger C says "registered canonical-home" (concept-home index), but Fn-scope and (C2) said "std/" fn / "std/-registered" type. A worker following Fn-scope literally would miss the documentedcount_named_bind(C1) case against the non-std/ canonical homesrc/v3/lenses/named_function_count.dag.Fix: Fn-scope bullet + (C2) text both updated to "registered canonical-home" with explicit pointer to
count_named_bindas the non-std/ canonical-home precedent. Consistency now spans trigger / type-scope / fn-scope / (C2) / Kills uniformly.[Exploratory]
v4.lens.concept_homewas defined asMap<FnId, File>only — type-scope canonical-home would need an extended index when non-std/canonical TYPES matter (beyond the fn example). Type-scope (C1) was relying on a concept-home authority the producer stage didn't actually provide.Fix:
v4.lens.concept_home's produces signature broadened toMap<DeclId, File>whereDeclId = FnId | TypeId. Same producer stage, broader output — no new derived stage; type-scope canonical-home authority lives in the same record as fn-scope. Facts Flow Forward / P2 preserved (one producer, multiple consumers).Test plan
Map<DeclId, File>is the right broadening (vs creating a separateconcept_home_typestage). The single-source-of-truth argument is the load-bearing claim.reusable byline correctly notes the dual-consumer pattern (L1.8 fn-home class + L1.12.b fn + type canonical-home authority)Squash-merge-post-merge note: cursor's review fired against the canonical-home generalization commit on PR #3479's branch; operator merged #3479 before this reconcile commit landed. This PR re-applies the fix off post-squash main.
🤖 Generated with Claude Code