Skip to content

spec(t27f): petal J JOBS -- job list, timeline and badge from job_kind.t27 - #12303

Merged
github-actions[bot] merged 1 commit into
masterfrom
claude/viz-petal-jobs
Oct 25, 2026
Merged

github-actions[bot] merged 1 commit into
masterfrom
claude/viz-petal-jobs

Conversation

@gHashTag

Copy link
Copy Markdown
Collaborator

Closes #12302
Refs #12173

What

Petal J JOBS, row 9 of specs/t27f/petal_viz_plan.t27. It answers: "Which lab jobs are queued, running or done, and of what kind?"

One new file, specs/t27f/petal_jobs_viz.t27. It is written against viz_contract.t27 in the order of the reference petal S and follows docs/nona-03-manifest/VIZ-PETAL-GUIDE.md (#12282).

  • Source, not copies. The rules come from two specs:

    Shown Source
    Gate word and class job_kind: ljk_gate_word, ljk_gate_class
    Can the node take it ljk_node_takes, ljk_offer
    Next move ljk_next (ADMIT, VOID, WAIT, RETRY)
    Verdict proof: job_verdict, wanted_after
    Sample nodes ljk_sample_desktop, ljk_sample_laptop, ljk_sample_phone
  • Views. A job list, a timeline (one cell per job and tick) and a badge with queued, running and done counts, all over one VizState. Every event goes through viz_apply.

  • Inputs. The tick (stepper) and the node scenario (param: recorded, laptops on battery, phones on battery).

    • On a battery scenario, a laptop off mains cannot take a medium or heavy gate, so its jobs stay QUEUED.
    • A scenario other than the recorded one is a what-if, so the badge reads DEMO. The recorded scenario returns VERIFIED.
  • Plan. pjv_reps() equals pvp_reps(9) = 772, and viz_plan_ok holds. The plan is not edited.

Glue the petal owns, called out

  • Derived states. job_kind.t27 has no queued, running or done table, so the petal derives each state and never stores it:
    • QUEUED while ljk_offer does not place the job, or before its lease tick;
    • RUNNING while ljk_next says WAIT or RETRY;
    • DONE once it says ADMIT or VOID.
  • Recorded fixture. job_kind keeps no receipt log, so the receipt arrivals (PJV_VOTES, PJV_TOP, PJV_SECOND) and the lease ticks (PJV_START) are a recorded fixture in the petal. The rules applied to them are the source's; the header says so.
  • No host draws this petal yet.

Checks

  • t27c test-report specs/t27f/petal_jobs_viz.t27 --specs-dir specs: 34 tests, 34 pass, 0 fail, 0 vacuous, 1 invariant.
  • python3 tools/dupe_scan.py: no new duplicate body.
  • ASCII only, no home paths, one file changed.

🤖 Generated with Claude Code

…d.t27 (Closes #12302, Refs #12173)

Petal J (row 9 of petal_viz_plan.t27) answers: which lab jobs are
queued, running or done, and of what kind?

specs/t27f/petal_jobs_viz.t27 shows six lab jobs. The views read one
VizState: a list (gate, class, state now), a timeline (one cell per job
and tick) and a badge (queued, running and done counts plus the truth
label). Gate words, classes, offers and next moves come from job_kind.t27
(ljk_gate_word, ljk_gate_class, ljk_node_takes, ljk_offer, ljk_next) and
the agreement verdict from proof.t27 job_verdict.

job_kind keeps no state table, so the states are derived, never stored:
- QUEUED while ljk_offer does not place the job or before its lease tick;
- RUNNING while ljk_next says WAIT or RETRY;
- DONE once ljk_next says ADMIT or VOID.
The receipt arrivals and lease ticks are a recorded petal-side fixture;
the header says so.

The inputs are the tick (stepper) and the node scenario (param). A
scenario other than the recorded one is a what-if, so the badge reads
DEMO; the recorded scenario returns VERIFIED. pjv_reps equals
pvp_reps(9) = 772, and viz_plan_ok holds.

test-report: 34 of 34 pass, 0 vacuous, 1 invariant. dupe_scan: no new
duplicate body. The plan is not edited.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@tri-claw

tri-claw Bot commented Oct 25, 2026

Copy link
Copy Markdown

Summary by t27-bees

Checked by the t27 compiler

t27c parse, parse-complete and typecheck on each changed .t27 file at b0066e3. Nothing was generated, built or run. A pass means the file is well formed, not that it is right.

  • specs/t27f/petal_jobs_viz.t27: parses and typechecks.

Read by the model

This PR adds a new visualization petal (petal_jobs_viz.t27) that renders a job list, timeline, and status badge by deriving QUEUED/RUNNING/DONE states from job_kind.t27 rules and a recorded fixture of receipt arrivals and lease ticks. It implements row 9 of the petal viz plan and passes all 34 tests with the expected replication count.

Worth a look

  • specs/t27f/petal_jobs_viz.t27 (entire file, ~1710 lines): The full diff was not shown, so I cannot point to specific lines. A spec of this size deriving state from job_kind rules and a local fixture carries risk: if the fixture's lease ticks or vote sequences diverge from what ljk_next/ljk_offer would actually produce under the sampled node scenarios, the timeline and badge will misrepresent the source logic. Verify the fixture matches the source semantics for all three sample nodes under both recorded and battery scenarios.

  • specs/t27f/petal_jobs_viz.t27 — derived state logic: The petal computes QUEUED/RUNNING/DONE from ljk_offer, ljk_next, and lease ticks rather than reading a canonical table. If job_kind later adds or changes its verdict semantics (e.g., new job_verdict values or wanted_after behavior), this derivation will silently drift. Consider adding a cross-spec invariant or test that the derived states align with job_kind's own notion of completion.

  • specs/t27f/petal_jobs_viz.t27 — battery scenario gating: The description notes laptops on battery cannot take medium/heavy gates, leaving jobs QUEUED. If ljk_node_takes or ljk_offer treats battery state differently than the petal assumes, the what-if badge (DEMO) and timeline will show incorrect queue depths. Check that the petal's scenario logic exactly mirrors job_kind's node-takes logic.

  • specs/t27f/petal_jobs_viz.t27 — viz_apply event flow: Every event goes through viz_apply per the contract. If the petal's event types or state transitions don't cover all VizState mutations required by the three views (list, timeline, badge), the stepper or scenario selector may produce stale or incomplete renders. Confirm the viz_plan_ok proof covers all view projections.

  • specs/t27f/petal_viz_plan.t27 (row 9 / pvp_reps(9) = 772): The plan is not edited, but the new petal must satisfy the existing replication count. If pjv_reps() diverges from 772 under any config, the plan check will fail. Ensure the replication logic is stable across all supported VizParam combinations.


Read: 1 files, +1710 -0, the whole diff up to 60000 characters (the rest was not read). Head b0066e3. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-25 06:46:28 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 27
PRs with All Checks Green 23
READY 5
FAILING 27
PENDING 0
NO CHECKS YET 0

These columns do not partition: 5 + 27 + 0 + 0 = 32, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=55c0f1b1b32d != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

This was referenced Oct 25, 2026
This was referenced Oct 25, 2026
@github-actions
github-actions Bot merged commit b19b3e4 into master Oct 25, 2026
37 checks passed
@gHashTag
gHashTag deleted the claude/viz-petal-jobs branch October 26, 2026 03:42
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.

spec(t27f): petal J JOBS interactive visualization (petal_jobs_viz.t27)

1 participant