[teamleaderleo]

The nightly status cannot identify which artifact-tree publisher blocks a build. The request was: “The nightly-stale line doesn't name what blocks it” and “A tree owner queued more than 3 min should show up as the nightly's blocker.”

Publish small observational artifacts from the existing decisions, before the heavy jobs queue:

• A pending nightly dependency names its canonical v2 tree key, selected build SHA and run attempt. It deliberately does not substitute the workflow-control SHA for the build source.
• A publisher records ownership only when the existing preflight or takeover decision says it owns an unpublished tree. The fixed artifact name supports exact-key lookup; its JSON contains the run ID and attempt, which readers must match against the current attempt.
• Uploads are advisory, capped at one minute and retained for three days. Missing, expired, ambiguous or old-attempt evidence means unknown. No claims, workflow permissions, runner selection or release gates change.

Contract: nightly-tree-dependency-KEY-BUILDSHA-attempt-N contains tree-dependency.json; cmux-tui-tree-owner-KEY contains tree-owner.json. JSON fields are schema_version:1, kind, key, run_id, run_attempt, plus build_sha only for a dependency. Owner markers use overwrite for a rerun; consumers must still reject an old attempt. Runs created before this producer lands cannot be retroactively identified from these markers.

Validation: fleet run 41278321960 passed all 33 Python tests, the nightly-resolver check and the 231-workflow permission scan. Its terminal receipt binds tested_sha=3d4b174746b5ed17b2f91f5aceead2f11df999f4 to snapshot 4913d3a2dd08b2789b6c9a2c4d0bb70e34d72545, with exit 0 in 24.709 s on 16 CPUs. Existing warm test snapshot path is reused; no app compile or runner routing change is needed.

Independent Opus 5.5 medium review: SHIP at the same full head. Nonblocking follow-ups: #30227.

Prior art: preserves #28197's tree-at-install behavior, #26800's distinction between publication and daemon testing, #26781's bounded owner election and #28764's compatibility-tree resolution. The new evidence uses the canonical key, not a compatible published alias. The overlap helper found no open PR for this change.

Agent session: agent session

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review 3d4b174: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr30221 -f ref=lane/nightly-tree-source-marker -f platform=macos -f backend_mode=local

red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on c9b1473 to compare; do not merge until green; see lane-rules

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4130052256501 (28aa638015)

[teamleaderleo]

Owned by an agent session · session

[cubic-dev-ai]

2 issues found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/cmux-tui-artifacts.yml">

<violation number="1" location=".github/workflows/cmux-tui-artifacts.yml:1099">
P3: This observation step runs a script that is only checked out when `owner_run_id` is set. When `owner_run_id` is empty, the script is missing and the step fails on every run, showing red in an otherwise green job. Gate the step on `owner_run_id != ''`, which is the only case where the owner marker can be produced.</violation>
</file>

<file name="scripts/ci/nightly_tree_source.py">

<violation number="1" location="scripts/ci/nightly_tree_source.py:40">
P2: The docstring tells readers to match only `run_attempt`, but the owner name has no run ID, so exact-name lookups return markers from earlier runs. Those markers pass an attempt-only check whenever the attempt numbers match. Readers must also match JSON `run_id` against the current run, and the docstring should say so.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The docstring tells readers to match only run_attempt, but the owner name has no run ID, so exact-name lookups return markers from earlier runs. Those markers pass an attempt-only check whenever the attempt numbers match. Readers must also match JSON run_id against the current run, and the docstring should say so.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At scripts/ci/nightly_tree_source.py, line 40:

<comment>The docstring tells readers to match only `run_attempt`, but the owner name has no run ID, so exact-name lookups return markers from earlier runs. Those markers pass an attempt-only check whenever the attempt numbers match. Readers must also match JSON `run_id` against the current run, and the docstring should say so.</comment>

<file context>
@@ -0,0 +1,56 @@
+        value["build_sha"] = sha
+        name = f"nightly-tree-dependency-{key}-{sha}-attempt-{value['run_attempt']}"
+    else:
+        name = f"cmux-tui-tree-owner-{key}"
+    return name, value
+
</file context>

[cubic-dev-ai]

P3: This observation step runs a script that is only checked out when owner_run_id is set. When owner_run_id is empty, the script is missing and the step fails on every run, showing red in an otherwise green job. Gate the step on owner_run_id != '', which is the only case where the owner marker can be produced.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At .github/workflows/cmux-tui-artifacts.yml, line 1099:

<comment>This observation step runs a script that is only checked out when `owner_run_id` is set. When `owner_run_id` is empty, the script is missing and the step fails on every run, showing red in an otherwise green job. Gate the step on `owner_run_id != ''`, which is the only case where the owner marker can be produced.</comment>

<file context>
@@ -1068,6 +1090,27 @@ jobs:
+        continue-on-error: true
+        env:
+          TREE_KEY: ${{ needs.tree-preflight.outputs.key }}
+          OWNS_KEY: ${{ steps.recheck.outputs.takeover == 'true' && 'true' || steps.wait.outputs.takeover }}
+          TREE_READY: ${{ needs.tree-preflight.outputs.tree_ready }}
+        run: python3 scripts/ci/nightly_tree_source.py owner
</file context>

[teamleaderleo]

Review (claude-opus-5-5 medium): SHIP at 3d4b174

Scope: c9b1473..3d4b174 (5 files, +221). Read-only review of the diff and the surrounding workflow control paths via git show; nothing run.

Checked:

• Owner gate, tree-preflight: OWNS_KEY = steps.inspect.outputs.owns_key, TREE_READY = steps.inspect.outputs.tree_ready, and the script publishes only when owns_key == "true" AND tree_ready == "false". That is the same owns_key the build/build-windows gates read (needs.tree-preflight.outputs.owns_key).
• Owner gate, tree-owner-wait: OWNS_KEY uses the same expression as the job's takeover output (steps.recheck.outputs.takeover == 'true' && 'true' || steps.wait.outputs.takeover), which is what the build gates read. TREE_READY comes from needs.tree-preflight.outputs.tree_ready. The two branches can't both fire: owner-wait is skipped when preflight owns_key == 'true'.
• Pending dependency: TREE_KEY = steps.pending.outputs.key (written only when tree_pending=true, validated as 40 hex). BUILD_SHA = steps.build.outputs.build_sha, the commit the build chose, not github.sha. If BUILD_SHA is missing, the script refuses to publish rather than falling back (tested). The step sits right after "Choose the build commit" in resolve-nightly-cmux-tui-client, before chief-key/superseded and before every downstream build job.
• Payload/naming: schema_version 1, kind, key, run_id, run_attempt (positive ints, validated), plus build_sha for a dependency. Names are cmux-tui-tree-owner-<KEY> -> tree-owner.json (a stable name, overwrite: true, so a rerun replaces the earlier attempt's artifact; readers compare run_attempt against the run's current attempt) and nightly-tree-dependency-<KEY>-<BUILDSHA>-attempt-<N> -> tree-dependency.json. Key and SHA are regex-validated before they go into GITHUB_OUTPUT, so no newline or output injection (tested with "KEY\nname=other").
• Advisory behaviour: every record step has continue-on-error. The upload runs only when a name was emitted, and has continue-on-error and timeout-minutes: 1. A failure leaves no marker, which the consumer reads as unknown. It adds no gate.
• Script availability: tree-preflight does a full checkout (fetch-depth 1). tree-owner-wait's sparse checkout adds scripts/ci/nightly_tree_source.py. The nightly resolve job checks out the full tip at depth 64. python3 is already used by each of these jobs.
• No changes to permissions, secrets, triggers, claim authority (cmux-tui-tree-claim.sh untouched) or concurrency. No contents API or REST log reads. The upload-artifact SHA pin (v7.0.1, 043fb46d…) is already used in the repo's nightly notarization workflow.
• Tests: tests/test_nightly_tree_source_marker.py checks the dependency binding to BUILD_SHA, the owner payload and stable name across attempts, that nothing is published for not-owner, unknown or ready, key/SHA/run-id/attempt validation, and the injection case. It is registered in tests/test-execution.toml as lane "manual" with a reason, so no new CI gate.

Follow-ups (non-blocking):

1. [follow-up] The tests exercise the script only. Nothing pins the workflow wiring, such as the owner-wait OWNS_KEY expression staying equal to the job's takeover output, or the inspect/pending step ids. A small YAML-contract assertion would catch drift if those gates change.
2. [follow-up] cmux-tui-artifacts.yml now uses upload-artifact v7.0.1 for these markers next to v4.6.2 for the existing feat-builder/deferred markers. That is harmless, since v4+ artifacts interoperate and these steps are advisory, but it's worth aligning on the next touch. If any runner in the tree-preflight/owner-wait pools lacks the Node runtime v7 needs, the marker silently goes missing ("unknown"), so NOW's consumer should show that state.
3. [follow-up] When tree_pending is true but build.already_published is also true, a dependency marker is still written. That's harmless as an observation, but the consumer may want to ignore dependencies of runs that built nothing.

No blocking findings.