Skip to content

Native SCM Phase 0: partial Git-use census and CAS consumer cut - #11317

Merged
briansrls merged 8 commits into
mainfrom
session/quick-moth-77
Sep 14, 2026
Merged

briansrls merged 8 commits into
mainfrom
session/quick-moth-77

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 13, 2026 •

Copy link
Copy Markdown
Contributor

6 uses enrolled. Remaining live-use population NOT enumerated. No unexamined use typed as Unclassified. No execution rung claimed.

This is the explicitly incomplete Phase 0 cut authorized by the parent’s amended exit gate. It records the existing Git authority honestly and prevents the next SCM lane from assuming that the shared CAS realization is already suitable. It implements no SCM route, removes no Git call, changes no provenance-vertical file, and authors no Rust wall wiring.

The appendable .dag ledger has role counts 1–6 of 0 / 3 / 2 / 1 / 0 / 0. Uncovered verdict populations retain named use rows, not counts. The pure direct-import policy joins expected pre-parse source paths against parsed records in both directions, refuses missing/unavailable populations and unrostered protected imports, and declares the disposition selector as a future reporting-consumer frontier, not current production consumption. The independent source-path producer is a declared frontier: no executing host connection is claimed. Bridge Landed is not evidence-sealed here; its exclusive evidence-bound construction remains a named capability gap.

Coverage is recorded on the wall’s failure-mode row: direct .dag imports are its policy subject; Rust uses are unreached; configured/opaque .dag process invocation is a KNOWN BYPASS. Import checks do not establish Git-free SCM execution. Roster growth approval remains review diligence, separate from import closure.

The CAS ruling answers three existing arms suffice from their payloads. Missing, occupied and stale slots remain distinguishable in the expected/observed pair; read-back is orthogonal to a committed receipt and cannot undo it. The named Phase 1 cut orders 2A contractual exclusive, complete, durable publication before 2B outcome fidelity, at the existing filesystem/CAS homes, with mandatory wet controls before native SCM may consume the provider. Final-directory-entry durability is not inferred from syncing a private staging file. The cut names target-generation and independent per-workspace stage/base consumers without declaring them prematurely.

Four recurring-failure rows record source-verified findings: incidental realization property borrowed as a contract; store refusal widened into contention; unreadable source omitted from a dependency census; and execution bypassing a direct-import policy. These are SOURCE-VERIFIED readings of contract mismatches, not executed reproductions.

Validation: staged whitespace check and pre-commit passed. A targeted remote compile of the first failure row passed. The remote compiler built, but the pure control run stopped with HostBudgetUnreadable before executing controls (receipt). The requested local run refused because this checkout has no built interpreter. No budget override or substitute revision was used. The targeted policy-closure compile FAILED with two blocking diagnostics: nullary function parameters bridge and native are rejected as missing functions (receipt). Source inspection locates the nonempty-parameter callability test in v1.compiler.infer::infer_expr_body. This substrate blocker was reported to the parent; no spelling workaround or compiler edit is authored here. The PR is not merge-ready.

Follow-up owned by the parent: close the independently discovered production Git-use population and join every use identity to this ledger. The census population is not closed; this is a separate later lane, not an implicit addition to ticket 2. The required-parse projection/invocation and its seven exact-path controls remain outstanding and NOT APPROVED: a scaffold-admission verdict on that exact bounded construction is still open with the operator, so no Rust wiring may be authored until it lands. A specification of what may be approved is not an approval; per docs/plans/scaffold-admission-doctrine.md approval is an observed fact bound to an exact head. The present PR claims neither a required-lane wall nor a production landing selector.

@gunbai-bot

gunbai-bot Bot commented Sep 13, 2026

Copy link
Copy Markdown
Contributor Author

Addressed review 65716 in 5d4b725 using DESIGN §3c's explicit frontier arm. The previous claim of a current “census reader” was inaccurate. The declaration now names the planned gunbc.git_use_census.report::report_git_uses consumer in the parent's separate census-completion follow-up, its route through git_use_rows and git_use_disposition, and its execution trigger. It explicitly says that entry does not exist today. Production authority selection belongs to ticket 6, not Phase 1's CAS consumption. The disposition fields remain required census content under the amended brief; this change claims future consumption, not an implemented report. I removed the projection-equals-input test and the prose citing it as coverage.

There is also a newly retrieved blocking validation result: the targeted compile failed with bridge and native not found in scope (receipt). In v1.compiler.infer::infer_expr_body, the local-callable branch uses resolved.params being nonempty to recognize a function binding, rejecting these declared nullary function parameters. I reported this substrate blocker to the parent for repair at its existing authority. I have not changed the spelling to evade the inference path or authored an out-of-scope compiler fix. The PR is not merge-ready, and the validation document now records this compile failure rather than pending status.

— sent from quick-moth-77

@gunbai-bot

gunbai-bot Bot commented Sep 13, 2026

Copy link
Copy Markdown
Contributor Author

Follow-up to review 65716: 205049f9124 makes the policy frontier's trigger explicit: the existing required parse path supplies independently discovered source identities plus parsed import records to the policy, carries its total result to the host gate, and executes the refusing and accepting controls. Approval or arrival of wiring does not discharge that frontier, and witnesses are not described as production consumers.

The data-versus-nullary decision is to retain the selector. The constant dispositions already inhabit data GitUseRow declarations. bridge and native are deferred computation parameters, not declarations returning constants: the selector invokes only the chosen branch. Supplying result values would change that contract to selection between already supplied results. I would retain deferred route selection with a working compiler, so I have not changed the specimen or added dummy arguments to evade the defect.

The parent has dispatched the nullary-callable inference repair as a separate lane, owning the root cause, discriminating execution evidence, and failure-mode row. This PR remains parked on that upstream repair and a successful compile of the unchanged specimen. No merge readiness is claimed.

— sent from quick-moth-77

git_use_covers_import took (row, module_name, imported_module) and its only
caller — the index fold — passed the row's own owner and target straight back
in. Two of its three conjuncts therefore compared a value to itself, and its
surface match re-derived what the caller had already destructured, so the only
conjunct that could fail at the one site that ran it was the role/authorization
check. A conjunct that cannot fail where it is called is not a weaker wall; it
is a decoration that later reads as coverage (DESIGN 4b).

Replaced by git_use_row_admits_its_import(row), which asks the discriminating
question and nothing else. Module/target is what the index is KEYED by, and
membership is already git_import_authorized's job, so nothing is lost and one
authority stops being restated at two grains.

Found by review 65735.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Qy8ErCHX3Npuvd6P7RPe3
@gunbai-bot

gunbai-bot Bot commented Sep 13, 2026

Copy link
Copy Markdown
Contributor Author

Both findings from review 65735 verified against the source. One is fixed in 036882d0d1a; the other is agreed and is exactly why this PR is not being merged.

git_use_authority.dag:174-186 — the tautological predicate. Fixed.

Confirmed precisely as described, and worse than "two conjuncts are redundant": git_use_covers_import had exactly one caller in the corpus — the index fold — and that caller read owner and target off the row and passed them straight back in. So (row.consumer.module_path as String) == module_name and (target as String) == imported_module compared values to themselves, and the surface match re-derived the arm the caller had already destructured. The only conjunct that could fail at the only site that ran it was git_authorization_matches_role. A conjunct that cannot fail where it is called is not a weaker wall — it is a decoration that later gets cited as coverage (DESIGN §4b).

Replaced with git_use_row_admits_its_import(row), which asks the discriminating question and nothing else. Nothing is lost: the module/target pair is what the index is keyed by, and membership is already git_import_authorized's job, so the deletion removes one authority being restated at two grains rather than removing a check. The rationale is recorded as an annotation at the declaration so the shape does not get reintroduced.

git_use_authority.dag:43 / :82 — knowingly red source. Agreed, blocking, and the PR stays parked.

No disagreement, including the sharpening: git_use_disposition is in the same closure that roster.dag and src/v2/test/claim/git_import_authority_test.dag import, so the failure is the whole policy closure, not just the selector specimen. The PR body and docs/plans/native-scm-census-coverage.md say the compile is red, but they frame it around the two bridge/native diagnostics, which reads narrower than the truth. That framing is the fair part of the criticism even though the red itself was already disclosed.

The remedy you name is the one already in force: land this after the inference repair, not before. That repair is dispatched as its own lane against v1.compiler.infer — a local binding whose resolved params count is zero is discarded and resolution falls through to global lookup, so a declared fn() -> R is reported as not found. It is a floor defect in its own right (names resolve, applications bind), and note that the path does not refuse but silently retries the name globally, so the diagnostic points away from the real cause.

To be explicit about what is not being done here, since it is the tempting move: the selector keeps its deferred fn() -> R branches. The six disposition constants already inhabit data rows; bridge/native are computation parameters, and generic route selection must invoke only the chosen computation — that contract would change if they became eagerly supplied values, even with a working compiler. Adding a dummy argument or reshaping the specimen to evade the defect is refused under DESIGN §5's workaround rule, and the specimen is the evidence the repair lane needs.

No merge is requested. This PR is parked until the inference repair lands, at which point it compiles, the controls run, and merge readiness gets re-assessed against refreshed reviews and CI — not before.

— sent from still-bat-15

@gunbai-bot gunbai-bot Bot mentioned this pull request Sep 13, 2026
6 tasks
@briansrls

Copy link
Copy Markdown
Contributor

Named downstream consumer; no scope expansion requested for this PR.

A blob-backed immutable corpus will need the Phase 1 CAS provider after its ordered 2A/2B gate closes. Its later requirements:

  • Manifest entries reference Fabric SHA-256 payload blobs without also storing those payload bytes as SCM authored-source objects.
  • The corpus head is a distinct named CAS slot, advanced only from its exactly observed prior generation.
  • Immutable blobs and the referenced manifest closure are durably verified before the head advances.
  • Committed, precondition-failed, store-refused, and committed-with-readback-unavailable remain distinguishable.
  • gunbc.scm.supersession is not reused as the ordinary ref authority.

Please sequence this as a native-SCM follow-on, or explicitly delegate a child lane after the provider gate. No implementation is requested in the present Phase 0 PR. The Fabric origin side is gunbc#11319 (filesystem realization of the fabric M0 origin), which does not touch the CAS homes this PR names.

🤖 Generated with Claude Code

The coverage note said the remaining live-use population was unknown. That is
true for Rust uses and for configured .dag process invocations, which have no
producer that enumerates them. It was false for ParsedDagGitDependency -- the
one surface this policy actually covers -- whose population is derivable from
the same import fact the policy consumes. Calling a derivable number unknown
understates what is already in hand, and it is the reading a later lane would
have trusted.

Read at this revision: 217 non-fixture modules import extdeps.git/github
directly, 34 of them inside dag/extdeps (authority side), so 183 consumer-side
uses against 2 enrolled rows. Recorded as a transcribed reading with its
derivation named, and explicitly not an oracle: no entry point re-derives it,
so it rots (DESIGN 6). Standing up that producer is the first obligation of the
census-completion lane.

Also records a positive result: zero modules under dag/gunbc/scm/ carry a
direct extdeps.git or extdeps.github import at this revision -- the wall's own
subject, measured clean, and silent about the configured-process bypass no
import fact can see.

Found by review 65752.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Qy8ErCHX3Npuvd6P7RPe3
@gunbai-bot

gunbai-bot Bot commented Sep 13, 2026

Copy link
Copy Markdown
Contributor Author

Review 65752, both findings checked against the tree.

The 217 count — correct, and the "unknown" was wrong. Fixed in 9ed67b810a3.

I reproduced it independently and it lands exactly: 217 non-fixture .dag modules under dag/ and src/ carry a direct module-level import extdeps.git* / import extdeps.github*. The refinement worth adding is the partition — 34 of those are inside dag/extdeps/ and are the authority side rather than consumers, so the consumer-side population is 183 against 2 enrolled ParsedDagGitDependency rows.

The finding is right for the reason it gives: this is the one surface the policy actually covers, and its population is derivable from the same import fact the policy consumes. Calling it unknown understated what was already in hand, and it is precisely the sentence a later lane would have trusted when deciding the census was as closed as it could be. The blanket claim is now split by surface: genuinely unbounded for Rust uses and for configured .dag process invocations, which have no enumerating producer; derivable, with its derivation named and its current reading given, for direct imports.

Two things I deliberately did not do. I did not enroll 183 rows — each needs a role, a bridge disposition and a cutover disposition checked against its consuming declaration, which is the census-completion lane, not a number I can make true by typing it. And I did not leave the figure standing as an oracle: it is marked a transcribed reading that will rot, because no entry point re-derives it (DESIGN §6, name the instrument rather than its output). Standing up that producer is now named as the completion lane's first obligation, which is what turns this surface from a number in prose into a closed identity join.

One positive result fell out of the count and is now recorded: zero modules under dag/gunbc/scm/ carry a direct extdeps.git or extdeps.github import at this revision. That is the wall's own subject measured clean — and as narrow as it sounds, since it says nothing about the configured-process bypass that no import fact can see.

The non-compiling closure — standing position, unchanged.

This repeats review 65735's blocking finding, which I answered above and agree with, including the part that the failure is the whole policy closure rather than the selector alone, so the five test fn declarations in src/v2/test/claim/git_import_authority_test.dag are green-by-absence. Your sequencing instruction is the one in force: this lands behind the nullary-callable inference repair, which is dispatched as its own lane against v1.compiler.infer (a local binding with zero resolved params is discarded and resolution falls through to global lookup, so a declared fn() -> R reports as not found — and the path does not refuse, it silently retries the name globally, so the diagnostic points away from the cause).

No merge requested, and none will be until that lands, the closure compiles, and the controls actually execute.

— sent from still-bat-15

@gunbai-bot gunbai-bot Bot mentioned this pull request Sep 13, 2026
6 tasks
…tions

The selector took two deferred zero-argument branches so that selection chose
which computation to INVOKE rather than which value to return. That shape is
right and is not abandoned -- but v1 inference discards a local callable whose
resolved parameter count is zero, so it does not compile, and a declaration the
compiler refuses is not a declared frontier. DESIGN 3c's admissible middle
state presumes the declaration is well formed under the current substrate.
Landing it parked non-compiling source in the required-witness claim home and
left every test declaration importing this module green by absence.

So the selector lands with its consumer -- the report entry that renders each
row's selected disposition -- in the lane that also has the dispatched
nullary-callable inference repair. Evading the defect with a dummy argument or
eager values stays refused; the specimen is that lane's evidence.

NOT cut: the mode type and the two row disposition fields. Which disposition
applies is a fact about the mode, and every census row is required to state a
bridge disposition and a cutover disposition -- that is the substance of the
census, it is well formed, and it compiles.

Also drops the transcribed 217/183 counts in favour of naming the derivation
that produces them. Fixing "unknown" did not license transcribing a number no
entry point re-derives (DESIGN 6); standing that entry point up is the
completion lane's first obligation.

Found by review 65773.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Qy8ErCHX3Npuvd6P7RPe3
@gunbai-bot

gunbai-bot Bot commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

Review 65773. The first finding is right and I have taken it — with one half declined, and the reason matters. 765cd603deb.

Cut: the selector. Kept: the modes and the two disposition fields.

native_authority_select and git_use_disposition are gone from this PR. Your reasoning is the part I want to agree with explicitly, because it is sharper than "it does not compile": DESIGN §3c's admissible middle state presumes the declaration is well formed under the current substrate, and a known-rejected one is not a declared frontier — it is a dangling declaration whose route does not exist at any rung. That distinction is what makes this a defect rather than a scheduling preference, and I had been treating it as the latter. Landing it also left the five test fn declarations importing this module green by absence, which is the outcome §5 exists to prevent.

I did not cut the two disposition fields, and I want that on the record rather than passed over. Every census row is required to state a bridge disposition and a cutover disposition — that is the substance of the census and the thing the exit gate asks for, all six rows populate both, and the pair is well formed and compiles. Which of the two applies is a fact about the mode, not about the row, so NativeAuthorityMode stays with them. They sit in the honest middle state with a named consumer and a trigger; the selector could not, because it was rejected. Cutting them would have removed the deliverable to fix the defect.

The selector lands with its consumer — the report_git_uses entry — in the lane that also carries the nullary-callable inference repair. The deferred-branch shape is not being abandoned: choosing which computation to invoke rather than which value to return is the distinction that matters once a route has effects. Evading the defect with a dummy argument or eager values stays refused under §5, and the specimen is the repair lane's evidence.

The 217/183 transcription — correct, and I had cited the rule while breaking it. Fixed.

Both counts are out. Fixing review 65752's "unknown" did not license transcribing a number no entry point re-derives; naming it "a transcribed reading" was not a cure, since §6's objection is that the number becomes unreachable from the thing that owns it, not that it is unlabelled. The note now names the derivation — non-fixture .dag modules under dag/ and src/ with a direct module-level extdeps.git*/extdeps.github* import, partitioned by whether the module is itself inside dag/extdeps/ — and states that standing that recipe up as an entry point, joined to the ledger at identity grain, is the completion lane's first obligation. That answers 65752 (the population is derivable, not unknown) without answering it in rotting prose.

On verification, so this is not mistaken for a compile claim. I have not proven the closure now compiles. The only interpreter available to me locally is built at a different revision and fails to parse the current corpus wholesale, so it can establish nothing about this tree in either direction — and a green from a mismatched compiler would be worth less than no green. CI is the verification route and a run against 765cd603deb is in flight; the two prior runs failed, consistent with the red closure this commit removes. I will report what CI says rather than assert the fix worked.

No merge requested.

— sent from still-bat-15

git_use_row_findings and git_use_row_admits_its_import answered one question
about one row independently -- both destructured row.classification, both
called git_authorization_matches_role, both decided "is this row in good
standing". Not a shared read of a resolved fact: two sources that can produce
DIFFERENT values, with a direction that matters. Add an arm to
GitUseClassification, or a finding to the finding channel, and the index keeps
admitting an import the finding channel has already condemned -- a forbidden
import silently reclassified as authorized, which is the outcome this policy
exists to refuse. A fork gets consolidated later, so it is correctness, not
tidiness.

Standing is now a closed sum resolved by one fold. The finding channel projects
its findings; the index channel projects admissibility. Neither re-derives the
decision, and Condemned carries its findings rather than sitting beside a Bool,
so "condemned" and "why" cannot disagree.

Also deletes git_import_policy_control_suite from the witness. It had no call
site anywhere in the tree, was not a test fn so discovery never ran it, and its
body re-invoked the six test fn declarations discovery already owns -- dangling
by DESIGN 3c and duplicated by DESIGN 2, while its own comment described a
consumption that did not exist. The six test declarations are the entries.

Found by review 65788.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Qy8ErCHX3Npuvd6P7RPe3
@gunbai-bot

gunbai-bot Bot commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

Review 65788. Both findings verified and both fixed in a1a79b6de1c. The second is on code I introduced two commits ago, and it is the sharpest finding this PR has had.

git_use_row_findings / git_use_row_admits_its_import — one question, two independent answers. Fixed.

Confirmed, and the part that makes it blocking is the direction of the divergence, which the finding states and I want to restate because it is the whole point: these were not a shared read of a resolved fact, they were two sources that can produce different values — so add an arm to GitUseClassification, or a finding to git_use_row_findings, and the index goes on admitting an import the finding channel has already condemned. A forbidden import silently reclassified as authorized is precisely the outcome this policy exists to refuse, which puts the fork in §2/§3's "correctness concern, not a style one" and not in the tidiness pile.

Worth owning: I created git_use_row_admits_its_import in 036882d0d1a while fixing the previous review's tautological-predicate finding. The duplication pre-existed inside git_use_covers_import, but my fix made the two channels plainer without consolidating them — I removed a decoration and left a fork. That is the consolidation-later cost §2 describes, incurred by a reviewer's own remediation.

The shape now: standing is a closed sum resolved by one fold (git_use_row_standing), the finding channel projects its findings, the index channel projects admissibility, and neither re-derives the decision. GitUseRowCondemned carries its findings rather than sitting beside a Bool, so "condemned" and "why" cannot disagree either — a new classification arm or a new finding is one edit both channels inherit.

git_import_policy_control_suite — dangling. Deleted.

git grep agrees: exactly one occurrence in the tree, its own definition. Not a test fn, so required discovery never ran it; its body re-invoked the six test fn declarations discovery already owns; and its comment — "One local invocation prepares the policy closure once" — described a consumption that does not exist. Dangling by §3c and duplicated work by §2, and the comment made it worse by asserting the consumer.

Deleted rather than promoted to the single entry. The six test fn declarations are the required entries and discovery owns them by identity; collapsing them into one helper would trade six named controls for one Bool, so a single cell going red would stop naming which control failed. Your finding allowed either resolution and named the "not both" constraint, which is the actual defect.

Incidentally, that dangling function is also what I reached for when I tried to get a local execution receipt earlier — a helper with no consumer that nonetheless looks like the entry point is exactly the artifact that invites that mistake.

Merge readiness: not ready. One REQUEST_CHANGES outstanding on the prior head, 0 approvals, GitHub BLOCKED, and CI has not yet returned green on any head of this branch. A run against a1a79b6de1c will follow the one now in flight. I will not ask for a merge until CI is green on the exact head and the change still answers the request.

— sent from still-bat-15

CI's declarations gate refused this witness: it cited gunbc.bootstrap_control
import_baseline, and no module declares gunbc.bootstrap_control. That was the
single structural blocker on the floor lane (floor_class=structural,
blockers=1), and the gate was right. A DeclarationRef is a citation whether it
appears in production or in a fixture, so inventing a plausible module name to
stand in for "some bootstrap adapter" forks the namespace with a symbol nothing
resolves.

The row is hypothetical in its CLASSIFICATION, which is what the cell tests;
its consumer identity never had to be. It now cites the fixture that builds it,
and the synthetic parsed-import population names the same module so the
policy's consumer/module join still holds -- that population is a fact handed
TO the policy, not a claim about what this module imports.

Receipt from the same run: all six policy controls executed and passed
(v2.test.git_import_authority.*, standing=planned-and-passed), and
required-witnesses-build succeeded, so the closure compiles since the selector
was cut. This citation was what stood between the floor lane and green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Qy8ErCHX3Npuvd6P7RPe3
@briansrls
briansrls added this pull request to the merge queue Sep 14, 2026
Merged via the queue into main with commit 2fcd615 Sep 14, 2026
4 checks passed
@briansrls
briansrls deleted the session/quick-moth-77 branch September 14, 2026 16:56
briansrls pushed a commit that referenced this pull request Sep 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant