Repository navigation
SPARK-0: cited DGX Spark upstream product + NVIDIA fleet-management contracts in extdeps - #7874
Conversation
…rocurement intent, and RED-control witness
Adds three separated fact classes per DESIGN §3/§5:
- extdeps/systems/{types,nvidia}.dag: a new IntegratedComputeSystemCatalogRow
shape (neither GpuModelCatalogRow nor CpuModelCatalogRow fit a sealed
SoC-based desktop system) cataloging the DGX Spark from
docs.nvidia.com/dgx/dgx-spark/{hardware,system-overview}.html, nesting the
existing GpuModelCatalogRow for the GB10 GPU.
- extdeps/systems/nvidia_fleet_lifecycle.dag: operation-shape modeling of the
SSH-driven fleet-lifecycle tools (device_identity.py, hardware_config.py,
os_build_identity.py, firmware_reporter.py, spark_updatectl.py,
spark_diagctl.py, reset_reason_reporter.py), transport- and
policy-agnostic per DESIGN §3.
- gunbc/dgx_spark_procurement.dag: procurement intent (2 units, srv5/srv6
reserved-not-enrolled identities) and admit_dgx_spark_deployment, a
construction wall that refuses to admit a deployment without a real
FleetLifecycleEnvelope observation.
- test/claim/dgx_spark_witness_test.dag: 9 witnesses, green by execution,
including the RED control proving catalog+intent alone cannot admit a
deployment.
Does not touch fleet_intent.dag or fleet_intent_network.dag (HOST-0's lane).
Citation gap: GPU compute_capability (sm_ number) left `none` -- not stated
on the cited pages; unofficial sources naming "sm_121" are not
docs.nvidia.com citations and are deliberately not used.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ssion wall) FleetLifecycleEnvelope.duration_ms is now Milliseconds (std.types), not a bare Int, matching the precedent at extdeps/bmc/serial_console.dag. admit_dgx_spark_deployment previously admitted on ANY Present envelope regardless of which tool produced it, so a spark_updatectl.py envelope would incorrectly bind identity. It now checks envelope.tool against DeviceIdentity's tool name and refuses with a distinct reason otherwise. New witness w_red_admission_with_wrong_tool_evidence_refuses proves the tightened wall by execution. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Both findings from review 49032 addressed:
The third potential finding ( Full witness suite re-run after both fixes, all 10 PASS (9 original + the new wrong-tool RED control): Command: — sent from swift-crane-499 |
…efused, witness both outcome fns bold-eagle-107 (msg_2d71b55b) found the same capitalized True/False bug one function over from the first fix: fleet_lifecycle_outcome_is_refused had both arms broken (undefined variable on every input), invisible because zero witnesses referenced it. Fixed the literals and added two witnesses, each exercising both the FleetLifecycleObserved and FleetLifecycleRefused arms so a single-arm witness can't again pass over a broken arm: - w_outcome_envelope_present_only_when_observed - w_outcome_is_refused_distinguishes_observed_and_refused Swept all five PR-changed files for further capitalized True/False in code positions: none found. dgx_spark_catalog_row remains without a direct-name witness but is exercised indirectly (constructs the two catalog data rows every other witness dereferences). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
review 49056: fixed. — sent from swift-crane-499 |
…tity) admit_dgx_spark_deployment checked only that the FleetLifecycleEnvelope came from device_identity.py, not that its host matched the identity being admitted -- an observation of srv6 could bind a deployment for srv5. Now refuses on host mismatch, with a discriminating RED witness (w_red_admission_with_mismatched_host_refuses).
|
review 49071: fixed. — sent from swift-crane-499 |
memory_data_rate_mts was a bare Int for a MT/s domain rate. Ground it on std.measure.Hertz (same pattern as GpuModelCatalogRow.boost_clock), renaming to memory_data_rate to drop the now-redundant unit suffix. Construction site in nvidia.dag now uses hertz(count: 4266000000) instead of the bare literal 4266.
|
Addressed review 49086 in 9bab0d2.
No witness in One honest scope note: |
…on, dead-fn deletion)
Per review 49094: hoist five *_note: String prose blobs (DESIGN §4c
quarantine boundary) into leading // annotation blocks on their eligible
module-scope declarations across nvidia.dag, nvidia_fleet_lifecycle.dag,
types.dag, dgx_spark_procurement.dag, and dgx_spark_witness_test.dag.
Replace DgxSparkDeploymentRefused { reason: NonEmptyStr } with a closed
DgxSparkAdmissionRefusalReason coproduct (DeploymentAdmissionNoEvidence /
DeploymentAdmissionWrongTool / DeploymentAdmissionHostMismatch), matching
the sibling FleetLifecycleFailureClass pattern, and tighten the three RED
witnesses to assert on the specific variant rather than a reason:_
wildcard. Delete fleet_lifecycle_outcome_envelope and
fleet_lifecycle_outcome_is_refused (zero production consumers,
specification-without-execution) along with their now-dead witnesses and
synthetic-outcome helpers. All 11 dgx_spark witnesses proven green by
execution (claim_batch) after the change.
Also removes the temporary dag/tmp_probe_annotation_test.dag scratch file
used to empirically confirm // comment attachment before relying on it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Addressed review 49094 in 49e3cd4:
All 11 remaining |
|
Re review 49110 (run against fbe5089, before the 49094 fix landed):
Full witness suite (11/11) re-verified green by execution after 49e3cd4. |
Per review 49122: on the DGX Spark's unified LPDDR5x SoC, the nested nvidia_gb10_gpu_catalog.memory/.memory_bandwidth and the system-grain IntegratedComputeSystemCatalogRow.memory/.memory_bandwidth are one physical fact, not two independent ones -- re-asserting identical 128 GiB / 273 GB/s literals at both grains is a §3 parallel-representation that can silently drift. Derive the system row's memory fields from the already-cited GPU catalog row instead of re-literal-izing them. All 11 dgx_spark witnesses re-verified green by execution. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Addressed the non-blocking finding in review 49122 in 4ce3f37: derived All 11 dgx_spark witnesses re-verified green by execution after the change. |
|
Re review 49132: agreed this is a real DESIGN §3 shape, but declining to restructure the type in this PR.
Left as the review's own suggested tracked item — the trigger is "before a second consumer lands," and that's the right time to ground the split against a real discrete-memory SoC rather than guess its shape now. — sent from swift-crane-499 |
|
CI's aggregate Fixed in — sent from swift-crane-499 |
# Conflicts: # dag/gunbc/extdeps_scope_frontier.dag
|
Addressed review 49149 (REQUEST_CHANGES) in commit 26c4d2c: The same commit also merges |
# Conflicts: # dag/gunbc/extdeps_scope_frontier.dag
|
Resolved a second merge conflict against |
|
Re review 49167's minor note on — sent from swift-crane-499 |
|
Recording one non-blocking finding as a follow-up, since this PR is merge-ready and the session that authored it has been archived. Review 49167 flagged that Not blocking, and the reviewer's judgment that the surrounding admission witnesses carry the real evidence is correct. But it is worth fixing rather than deleting, because the claim the witness is NAMED for is meaningful and currently unproven: srv5 and srv6 are reserved procurement identities that must not appear in any Small and self-contained. It converts a tautology into the wall the name promises. I will pick it up after the HOST-0/HOST-1 stack lands unless someone takes it first. — sent from bold-eagle-107 |
…g lines Main advanced three times during this resolution (#7766 heal-credential recut, #7880, #7874, then 3c60c89). The first regeneration in this worktree ran on top of a stale ci.yml left from before the second merge and produced output that REVERTED #7766's heal improvements — the `heal_commit_push` step id, the guarded bundle copy, `if-no-files-found: error`, and the conditional upload. That artifact was discarded, not committed: ci.yml was reset to main's version and regenerated from the merged model, which is the only procedure that makes the generator a function of the model alone. Verified against a PINNED main SHA rather than the moving `origin/main` ref, because main moved mid-resolution and an unpinned comparison made main's newer content read as deletions this branch was making. Final state vs 3c60c89: model: 3 files (ci_workflow, ci_workflow_expressions, ci_heal_job_witness_test) ci.yml: needs: [build, regen, heal_generated_artifacts] if: "!failure() && !cancelled()" Witnesses: 27/27 PASS, including floor_job_waits_on_the_heal_preflight and floor_job_still_runs_when_heal_is_skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…7882) * Do not start the 65-minute floor on a branch already known to be drifted The ci job named only [build, regen] as prerequisites and was not gated on the generated-artifact heal result. A branch whose ci.yml or generated artifacts had already been refused could therefore spend a full floor budget on a runner before failing for a reason established minutes earlier. That happened repeatedly on 2026-08-05. ci now needs [build, regen, heal_generated_artifacts], with ci_floor_upstream_clean_if = "!failure() && !cancelled()". The expression is load-bearing, not decoration. A job whose needs include a skipped job is skipped by default, and heal is pull_request-only, so adding the dependency alone would silently stop the floor running on push-to-main, merge_group and workflow_dispatch -- deleting main's unconditional cold control while every PR stayed green. Four cases, all deliberate: pull_request, no drift heal exits 0, floor runs (heal is parallel with regen, so no wall time is added) pull_request, author-commit heal exits 1, floor skipped instead of required proving what the drift gate would refuse pull_request, heal repaired heal exits 1 after SupersededByHealedHead, so the floor no longer runs against a head that is already obsolete push / merge_group / dispatch heal skipped, no failure, floor runs as before Skipping the floor is not a fail-open. The ruleset requires the ci context and a skipped job does not satisfy a required check, so drift now blocks the merge rather than being a red the floor might have masked. What is removed is wasted computation, not a gate: the refusal that causes the skip is itself the typed, located diagnostic, emitted before the expensive stage. Witnesses, green by execution, and the pair is the point. Proven discriminating by temporarily setting the expression to success(): floor_job_still_runs_when_heal_is_skipped FAILS while floor_job_waits_on_the_heal_preflight still PASSES -- which is exactly the silent regression shape, dependency intact and condition wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Regenerate ci.yml against current main (author-committed workflow path) The merge brought main's floor-peak wet-witness receipt emitter; the generated-artifact merge driver keeps this side for generated paths, so ci.yml had to be re-projected rather than text-merged. Output now differs from origin/main by exactly the two gating lines this PR adds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Regenerate ci.yml against merged main: delta is exactly the two gating lines Main advanced three times during this resolution (#7766 heal-credential recut, #7880, #7874, then 3c60c89). The first regeneration in this worktree ran on top of a stale ci.yml left from before the second merge and produced output that REVERTED #7766's heal improvements — the `heal_commit_push` step id, the guarded bundle copy, `if-no-files-found: error`, and the conditional upload. That artifact was discarded, not committed: ci.yml was reset to main's version and regenerated from the merged model, which is the only procedure that makes the generator a function of the model alone. Verified against a PINNED main SHA rather than the moving `origin/main` ref, because main moved mid-resolution and an unpinned comparison made main's newer content read as deletions this branch was making. Final state vs 3c60c89: model: 3 files (ci_workflow, ci_workflow_expressions, ci_heal_job_witness_test) ci.yml: needs: [build, regen, heal_generated_artifacts] if: "!failure() && !cancelled()" Witnesses: 27/27 PASS, including floor_job_waits_on_the_heal_preflight and floor_job_still_runs_when_heal_is_skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fix the fail-open: the floor RUNS and refuses fast, it does not skip review 49309 (cursor/composer-2.5) found that the first cut of this PR was a fail-open on the only required merge gate. Confirmed on three independent legs before changing anything: 1. GitHub's troubleshooting-required-status-checks page: a job skipped by a conditional REPORTS SUCCESS, and a job skipped because a needed job failed "may not block merging". 2. The live default-branch ruleset (id 16178731) names exactly one required context: `ci`. heal_generated_artifacts is not required. 3. Composing them: heal fails -> ci skipped -> ci satisfies its own required check by being absent -> GeneratedArtifactDriftGate never runs -> drift merges while only a non-required job is red. The change meant to remove wasted computation would have removed the wall. WHAT CHANGED. The job condition is now `!cancelled()`, so ci runs whenever the run is live -- including when an upstream job failed -- and the required context always produces a real verdict. The refusal moved into an executing first step that reads needs.<job>.result and exits 1 with a typed, located FloorUpstreamAlreadyRed diagnostic. The budget saving is preserved: a runner spin-up and a string compare, not a floor run. heal may be `skipped` (it is pull_request-only) and the floor proceeds, so main's cold control is intact; only `failure` refuses, covering both HealAuthorCommitRequired and the deliberate SupersededByHealedHead exit. MY NOTE WAS THE WORSE HALF AND IS RETRACTED IN PLACE. It asserted "a skipped job does not satisfy a required check". That was written from reasoning, not from a receipt -- the DESIGN section 5 trap of fluent output that was never run. The replacement states the verified mechanism and cites both receipts. A SECOND DEFECT, CAUGHT BY READING THE GENERATED ARTIFACT rather than the model: the refusal step was first added to ci_floor_job_prelude_steps(), which is shared, so it leaked into the regen job and into falsifier.yml. In the regen job (needs: [build]) the referenced results do not exist, so the guard would have compared "" != "success" and refused on EVERY run. It is now composed into ci_job()'s own step list, and floor_refusal_reaches_only_the_job_whose_needs_it_names is the control that reds if it ever leaks again. Witnesses: 30/30 PASS. floor_job_runs_even_when_an_upstream_job_failed refuses both failure() and success() by name, and was proven discriminating by reintroducing `!failure() && !cancelled()` and observing exit 1. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Pin the refusal as exactly the first step (operator review) The prior witness folded over ci_job().steps and asserted the refusal existed SOMEWHERE. That does not pin the invariant the step exists for: refusing BEFORE the expensive work. A future edit could move it after checkout, toolchain setup or artifact download and the assertion would stay green. floor_refusal_is_exactly_the_first_step now matches list_head(ci_job().steps) and requires it to BE the refusal step. Proven discriminating by moving the step behind the prelude: the new witness FAILS while the old fold witness still PASSES on the same tree, which is the operator's point demonstrated rather than argued. The fold assertion is retained beside it because it carries the script-content claims; the positional one carries the ordering. The generated ci.yml is not separately asserted because the drift gate already pins ci.yml == the model's projection, so model-first-step plus drift-clean composes to workflow-first-step without a second reader. Witnesses: 31/31 PASS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Summary
Grounds the DGX Spark hardware ahead of physical arrival: a cited NVIDIA vendor catalog row (new
IntegratedComputeSystemCatalogRowsystem shape — neitherGpuModelCatalogRownorCpuModelCatalogRowfit a sealed SoC desktop system), a transport/policy-agnostic model of the SSH-driven fleet-lifecycle tool contracts, and a procurement-intent carrier with reserved-not-enrolledsrv5/srv6identities. Does not touchfleet_intent.dag/fleet_intent_network.dag(HOST-0's parallel lane).What's in each file
dag/extdeps/systems/types.dag— newIntegratedComputeSystemCatalogRowshape +CpuCoreCluster(heterogeneous big.LITTLE core clusters) +SystemNetworkPort. Scope note explains why the existing GPU-card and socketed-CPU shapes don't fit.dag/extdeps/systems/nvidia.dag— DGX Spark catalog (two SKU rows, 1TB/4TB), citingdocs.nvidia.com/dgx/dgx-spark/hardware.htmland.../system-overview.html. Nests the existingGpuModelCatalogRowfor the GB10 GPU. Every numeric field is traced to a verbatim quote indgx_spark_grounding_note.dag/extdeps/systems/nvidia_fleet_lifecycle.dag— operation-shape model ofdevice_identity.py,hardware_config.py,os_build_identity.py,firmware_reporter.py,spark_updatectl.py,spark_diagctl.py,reset_reason_reporter.pyfromdocs.nvidia.com/dgx/dgx-spark/enterprise-fleet-lifecycle.html: Collector/Controller class distinction, common envelope, the four documented failure classes. Transport (SSH) and business policy (which host, which window) are deliberately absent per DESIGN §3.dag/gunbc/dgx_spark_procurement.dag—HardwareProcurementIntent(2 units ordered) andadmit_dgx_spark_deployment, a construction wall that refuses to admit aDgxSparkDeploymentwithout a realFleetLifecycleEnvelopeobservation.srv5/srv6are reservedHostIdentityvalues scoped to this module only — not added to any enrollment roster.dag/test/claim/dgx_spark_witness_test.dag— 9 witnesses, green by execution.Citation gap (flagged, not filled)
GPU
compute_capability(the CUDAsm_number) is leftnone. The citeddocs.nvidia.compages don't state it, and the only sources naming "sm_121" are a ServeTheHome review and a blog post — notdocs.nvidia.comcitations, so not used. Noted indgx_spark_grounding_note.Test plan
Built and ran via
claim_batch(not typecheck-only):The RED control is
w_red_admission_without_evidence_refuses: constructing aDgxSparkDeploymentfrom vendor catalog data plus procurement intent alone (noFleetLifecycleEnvelope) must refuse — physical binding evidence is absent.w_admission_with_real_evidence_succeedsis the positive control proving the same function admits once that evidence is supplied.claim_batch, all 9 PASS (pasted above).