Online edition for BLOGE
0.9.8-RC1· facts verified 2026-09-15 · 中文
Chapter 31 — Project, Reactor, and Claim Capability
Chapter promise: Aggregate exact Requirement contributions only from a complete frozen cohort, reject borrowed children, and end with the highest evidence-backed decision capability plus named gaps.
Learning goals
- Explain why aggregation needs an authoritative inventory and one run cohort.
- Distinguish Project completeness from direct-module Reactor completeness.
- Observe cohort mismatch and borrowed-child rejection before trusting totals.
- Treat
ClaimCapabilityandmissingEvidenceas derived reader output.
Two valid children can still make an invalid parent
The decision module contributes one valid loan Case; the funding module contributes another. Together they meet minimumPassingCases: 2—but only if both belong to the same governance snapshot, selection, source commit, and parent run.
This is the aggregation version of a cut-and-paste report problem. Child validity is necessary; parent membership is a separate fact.
Project aggregation freezes discovery before execution
VerificationGovernedProjectEvidence evidence =
VerificationProjectRunner.runGovernedEvidence(
scenarioDirectory,
verifier,
VerificationSelection.all(),
projectIdentity,
outputDirectory);
The runner freezes Scenario discovery, effective selection, governance context, project POM identity, and source-bound child receipts before calculating the Requirement. If a required binding is absent or filtered out, it reports GOVERNANCE_BINDING_MISSING or GOVERNANCE_BINDING_FILTERED; it does not lower the minimum to fit the available children.
RC1 test aggregatesDistinctSuiteCasesAndRejectsAMissingGovernedChildBeforeBootstrap protects this distinction: separate Suite contributions may combine only through the Project aggregate that owns their complete inventory.
Reactor adds a different completeness authority
VerificationReactorRunner.runGovernedEvidence(...) reads the root pom.xml direct <modules> list. Every module supplied to the runner must match that inventory, literal GAV, Suite/Case inventory, shared Git commit, selection, and governance cohort.
In recomputesOneGlobalRequirementFromTwoIndependentModules, either module alone returns INVALID / GOVERNANCE_BINDING_MISSING with zero calls. The Reactor run executes both once, lists two qualified Suite identities, and recomputes one Requirement with two satisfied Cases.
Current Preview covers direct modules in one Git worktree. Nested reactors, arbitrary Maven profiles, external-parent effective models, and deployment topology remain outside this completeness claim.
Attack the cohort before reading the count
The test rejectsAReactorGovernanceCohortMismatchBeforeCustomerBootstrap changes only the second module's catalogId. The result is:
status = INCOMPLETE
reasonCodes = [REACTOR_GOVERNANCE_COHORT_MISMATCH]
module calls = 0 + 0
The runner rejects the parent before customer bootstrap. This is stronger than discovering a mismatch after two expensive or side-effecting executions.
Another attack runs two valid Reactor parents, then replaces one Suite in the first in-memory parent with a valid Suite from the second. reactorClaimRejectsAValidChildBorrowedFromAnotherParentRun drops capability to AUTHORING and restores SOURCE_BOUND_PROJECT_AGGREGATE as a TEAM_GATE gap. Valid child plus wrong parent still equals invalid aggregate.
Let Claims name the remaining decision boundary
VerificationClaimAssessment assessment =
VerificationClaims.assess(evidence, projectRoot);
ClaimCapability current = assessment.capability();
Map<ClaimCapability, List<VerificationEvidenceGap>> gaps =
assessment.missingEvidence();
| Capability | Evidence-backed decision context | Typical remaining gap |
|---|---|---|
AUTHORING | local diagnosis and witness discovery | source-bound Suite/Project evidence |
TEAM_GATE | team integration with continuity, replay, and CI-safe controls | governed aggregate or Oracle provenance |
GOVERNED_GATE | versioned business obligations and trusted Oracle provenance | attributed comparison and release attestation |
RELEASE_QUALIFIED | exact governed evidence and comparison signed for release | no missing item in the declared release contract |
Gaps are cumulative. A string written into JSON cannot promote the evidence, and a Policy cannot award itself a capability. A trustworthy FAIL may have strong provenance; capability still does not replace business status.
Lab: borrow one child
- Run a two-module parent and retain its external receipt.
- Run the same modules again into a second parent directory.
- Confirm each parent independently verifies.
- Replace one child projection in parent A with the valid child from parent B.
- Assess the mixed parent. Record
AUTHORINGandSOURCE_BOUND_PROJECT_AGGREGATE. - Restore parent A and draw the ownership links: root POM → parent run ID → child receipt → Suite contribution.
- End with a gap card: current capability, desired capability, missing evidence, owner, and next experiment.
Transfer: a multi-module billing release
Imagine tax, invoice, and ledger modules each publish valid child evidence.
Combining a tax child from yesterday's parent with today's invoice and ledger
children creates a readable but mixed cohort. Require one root build identity,
one parent run, and owned child receipts before claiming project completeness;
otherwise stop at AUTHORING and name the missing owner.
Chapter boundary
- Valid child evidence does not prove membership in a particular parent run.
- Project completeness does not imply direct-module Reactor completeness or deployment completeness.
- A Reactor total is meaningful only after inventory and cohort checks.
ClaimCapabilitystates the supported decision context; it neither changes the verdict nor approves a release.
Experiment acceptance card
- Expected and observed: Two valid children can still leave a parent capability gap.
- Failure and recovery: Borrow a child from another cohort; restore the frozen discovery set.
- Proof boundary: Proves Project/Reactor completeness, not acceptance of residual risk.
- Exercise contract: One parent and two children; replace one child; deliver the gap; stop when the borrowed child is identified.
Summary
Aggregation is not addition. It is addition under an authoritative inventory and one frozen cohort. The Claims reader then reports how far that evidence may travel and what still blocks the next decision. Chapter 32 runs the last controlled experiments: one DSL change and one BLOGE toolchain change.
Next: Chapter 32 — Change Attribution, Maven, and Release Decisions
Coding Agent: Open the versioned task guide.