jonnify·bcs /bcs/bus/jobs-are-entities/the-job-row

B3.2 · dive 1 — the job row

Three fields, one of them cargo.

A job is a hash at the job key — state, attempts, payload — and deliberately nothing more. Its surface is gated at enqueue, browse, pending_size, its pending home is a sorted set with every member at score zero, and the members are the job ids themselves — so the structure inherits the identity contract's ordering instead of maintaining its own.

Source: content/bcs3.2.md, quoting bcs_rung_3_2_check.out; the module is committed at runtimes/elixir/lib/echo_mq/jobs.ex.

The row, field by field. Three committed fields and one deliberate absence. Select a field to read its role and the law that put it there — or left it out.
state written 'pending' the lifecycle word attempts written '0' not yet incremented payload the cargo ids and parameters, never rows enqueued_at absent by design the two-clocks law
readout · Select a field. Three fields, one of them cargo — and the fourth that never existed, because mint time already lives inside the identity.
§1

The transcript

bcs_rung_3_2_check.out · verbatim · this dive reads boot and J1
content/echo_data/runtimes/elixir/bcs_rung_3_2_check.out · verbatimfrozen
boot: the registry grows by one -- JOB, work as a kind with identity and lifecycle
J1 surface ok -- the bus module's surface: enqueue, browse, pending_size -- scripts and key shapes are nobody's business
J2 idempotent ok -- enqueue is one script and idempotent by id: first call enqueued, second answered duplicate, the row untouched and pending holds 1
J3 kind ok -- kind policy lives in the script: an ORD id in the job position answers EMQKIND on the wire -- the key let it pass, the law did not
J4 dividend ok -- the order theorem's dividend: newest-first browse over the ids themselves returns the last five minted in reverse mint order; the very first job sits at the head; 301 pending, no second index anywhere
J5 cargo ok -- the cargo law holds: the payload carries ORD0Nt6z93U3dY and a quantity, never a row -- decoded and re-parsed on the far side of the wire
PASS 5/5
§2

The surface

content/bcs3.2.md · Where · Decisions

The boot line registers the kind before any gate runs: the registry grows by one -- JOB, work as a kind with identity and lifecycle. That is decision D-10 performing — work is a kind, minted, gated, browsed, audited, and one day replayed, platform scope, same bar as ARC.

J1 then gates the module's surface: enqueue, browse, pending_size — and the committed line adds the boundary in the same breath: scripts and key shapes are nobody's business. The module lives at runtimes/elixir/lib/echo_mq/jobs.ex; the script travels inside the module, SHA-pinned by Script.new and dispatched EVALSHA-first through the appendix's loader. Callers hold three verbs and never a key.

§3

The row

content/bcs3.2.md · What · Boundaries

A job is a hash at the job key — state, attempts, payload — "and deliberately nothing more. No enqueued_at field exists because the two-clocks law already placed that fact: mint time lives inside the identity (unixMs of the snowflake), and server-time fields belong to leases, which are Chapter 3.3's business. Three fields, one of them cargo."

Two honesty notes travel with the row, straight from the chapter's Boundaries. attempts is written but not yet incremented: the field belongs to this chapter's row, its arithmetic to the next chapter's transitions. And payload size is caller discipline at this rung; a policy cap is a later knob, not a silent truncation.

§4

The pending set

content/bcs3.2.md · What

Pending is a sorted set with every member at score zero, members the job ids themselves. Equal scores order lexicographically — byte-by-byte, which for branded ids is mint order — so the set is "simultaneously the FIFO (lex-min is the oldest job) and the browse index (lex-max-down is newest-first) and the time-range index (an id-prefix range is a time window)". The dividend is collected on stage by J4, which the third dive reads. The score-zero decision is forever: the lex law holds only under equal scores, so delayed and scheduled work will never mix scores into this set — B3.3 · The State Machine in Lua inherits a pre-stated plan, a separate sorted set scored by run-time.

The pending set, modeled. Six JOB ids minted in sequence for this model with the course's minting tool — demonstration data, not committed evidence; the committed figures sit in the frozen record above. The sort is performed live, byte by byte.
readout · Ask the model a question. Six members, every one at score zero; the bytes carry the chronology.

Static record — the six ids in mint order, every member at score 0: JOB0Nvmd8aV5iy · JOB0Nvmd8gSfSK · JOB0Nvmd8mzRRo · JOB0Nvmd8tnoZM · JOB0Nvmd90tmoy · JOB0Nvmd96ZlQG. Sorting a scrambled copy byte-by-byte reproduces exactly this order — lex order is mint order.

§5

References

sources · related

Sources

  • Valkey — Sorted setsthe same-score lexicographic family as a generic index; the different-scores caveat behind the score-zero decision
  • Valkey — ZRANGEthe REV and BYLEX forms behind newest-first browse; equal-score elements order lexicographically

Related