C.24:4.7 - Closure and worked cases

Close as a CallPlan when route order and budgeted enactment are the current question. Close as a CheckpointReturn after a bounded route probe, when one further route probe remains justified. Return to the domain prescription, A.15.7 or C.11 when the corresponding action basis reopens; return to the applicable neighboring pattern when pool treatment, selector declaration, readiness, execution, or publication becomes the current question.

Domain-prescribed action before Work.

In a constructed catalogue-maintenance case, CatalogueMethod_3 requires rebuilding a digest when the catalogue’s source checksum changes. That condition is established; no choice of action remains and the rebuild has not begun. Plan the two admitted Methods directly:

CallPlan:
  actionBasis:
    domainPrescribedAction:
      methodRef = CatalogueMethod_3
      prescriptionRef = catalogue_method_v3#changed-source-digest
      prescribedAction = rebuild_digest
      applicabilityAndStop = changed_source_checksum; stop_if_input_version_changes
  objective = digest_for_the_fixed_catalogue_version
  plannedCallsInOrder = [ReadCatalogueMethod_2, BuildDigestMethod_4]
  plannedBudgetEnvelope = {time<=10_minutes, cost<=catalogue_budget, risk<=read_and_derived_file_only}
  stopOrReplan = input_version_changes_or_budget_is_exceeded
  nextPlannedAction = confirm_required_entry_permission_then_run_read

The prescription fixes the action, while work-entry permission remains separate. If a permitted route probe is needed, its CheckpointReturn retains this same domainPrescribedAction branch and states the tested Methods, findings, spent/residual budget and next action. A changed prescription or input condition reopens the domain basis. Neither form invents an A.15.7 decision or completed Work.

A.15.7 decision into a known route.

During ongoing repository-repair Work, changed source facts make produce_patch_and_verify the next action under the current repair Method. Using the steering Method in A.15.7, the responsible maintainer makes that decision. The retained decision names the repair agent as intended performer, the changed-source fact, and test failure as the stop and feedback condition. Because the call plan relies on the decision later, the team retains it in one episteme identified under C.2.1. The episteme describes the situation-responsive decision; it is not a C.11 ChoiceResult.

CallPlan:
  actionBasis:
    situationResponsiveDecisionEpistemeRef = patch_action_decision_17
  objective = produce_patch_and_verify
  plannedCallsInOrder =
    - methodRef = InspectRepositoryMethod_4
      methodDescriptionRef = inspect_repo_route_v3
    - methodRef = EditCandidateMethod_2
      methodDescriptionRef = edit_candidate_route_v2
    - methodRef = TargetedTestMethod_7
      methodDescriptionRef = targeted_tests_route_v5
  plannedBudgetEnvelope = {time<=45_minutes, compute<=x2, cost<=y2, risk<=r2}
  stopOrReplan = targeted_tests_fail_twice
  nextPlannedAction = enact_now

The plan claims no call occurred. If the first call is performed, recover its dated Work, performer, assignment where current, Method, interval, plan ref, and trace representation through the direct patterns.

Unfamiliar route.

CheckpointReturn:
  actionBasis:
    fixedOptionChoiceResultRef = ci_route_choice_09
  objectiveOrTaskFamily = unfamiliar_ci_failure
  testedMethodRefs = [LogTraceMethod_2, MinimalReproductionMethod_5]
  evidenceRefs = [trace_result_1, reproduction_result_1]
  burnedBudget = 1_probe_cycle
  residualBudget = 2_probe_cycles
  recommendedNextAction = run_minimal_reproduction_once_more
  commitTrigger = reproduction_is_stable_and_required_evidence_is_current

Two vendor routes with one token. Vendor A and Vendor B both publish a route called search. vendor_a_search_v2 states scheme VendorA API, edition 2026-07, intended use repository text search, and selected Method RepositoryTextSearchMethod_3. vendor_b_search_v5 states scheme VendorB agent tools, edition 2026-08, intended use web source retrieval, and selected Method WebSourceRetrievalMethod_8. The shared token identifies neither binding; the description fields do. An executable adapter, if used, remains distinct from the Method it implements, and its execution remains separate Work.

Scale comparison, when current. The cheap C.19.1 probe for BatchSearchMethod_3 and IndexedSearchMethod_6 returns bounded scale comparison for the same repository-search task and 10k–100k files window. The comparison then uses elapsed time and missed-match rate from repo_search_benchmark_12, including uncertainty and cost limits, and warrants a preference for IndexedSearchMethod_6 only inside that window. If one Method is evidenced only on small text files and the other only on large mixed repositories, the comparison returns no scale-based preference. A project may separately cite a local policy or BLP-waiver; neither changes the empirical result.

Near misses. A route label with no recovered Method remains probe material. A plan with no Work is still intent. A trace row does not prove performer, assignment, Method, or service acceptance. A successful probe without a commit trigger is not rollout.

Transfer examples. The same result shape works for research assistance, program repair, and lab automation. The Methods and safety conditions differ; the plan/checkpoint boundary does not.