Skip to main content
Greenfield Production Systems

Artifact · Gate transcript

A gate transcript, annotated

A gate is an automated check that work must pass before it moves forward in the factory, and the transcript is the logged record of every check it met on the way. This is one work item's transcript: a single generated journey spec for the Bugzilla port (a bug update notifies its watchers), from catalog projection to a green suite run. The margin notes are ours; everything in mono is the machine's.

Lightly redacted: internal run and station identifiers are masked (████). Gate names, verdicts, details, and timings are verbatim. The source citations point into Bugzilla's public code, so they need no masking and you can check them yourself.

11 gate entries · 2 fail

The run

Each row carries a kind label: det marks a deterministic gate (a grep, a compiler run) whose verdict is mechanical, while llm marks a gate judged against a written rubric, where anything under 90 fails. Ten of these eleven entries are deterministic. The two red ones stay in the record; a transcript with no red entries reads as theater.

Gate transcript run ████-4f2a · bugzilla-port · journey bug-update-notify
  1. scenario-scoped-ids det ✓ pass 1.4 s
    Annotation: The scenario is projected deterministically from the behavior catalog; this gate checks that every generated test still carries its @catalog:<id> tag back to the behavior it covers.
  2. mapfromevent-namespace det ✕ fail 380 ms
    BugFieldUpdated handler subscribes to a short event name; expected bug.Events.BugFieldUpdated
    Annotation: The read-model gate rejects short event names. A handler that subscribes to BugFieldUpdated instead of bug.Events.BugFieldUpdated would silently never catch up, so it's a hard failure.
  3. mapfromevent-namespace det ✓ pass 410 ms
    re-run after namespacing; the handler resolves to bug.Events.BugFieldUpdated
    Annotation: A failed gate sends the work back to the station that produced it, and the re-run is logged beside the failure rather than over it.
  4. subscription-events-exist det ✓ pass 520 ms
    Annotation: Every event a handler subscribes to must be one some aggregate actually emits. A subscription to a non-existent event never reaches a test run.
  5. handler-casing det ✓ pass 95 ms
  6. assertion-floor det ✕ fail 240 ms
    scenario asserts the command succeeded but not the notification it emits; below the floor
    Annotation: Rejects a test that only checks the command returned success. A body that compiles but asserts nothing is the most expensive kind of green.
  7. assertion-floor det ✓ pass 230 ms
    re-run after asserting the notification event reaches the watchers
    Annotation: A failed gate sends the work back; the re-run is logged beside the failure, not over it, so the rework stays on the record.
  8. scenarios-typecheck det ✓ pass 6.2 s
    Annotation: The full TypeScript check, emitting nothing. Type errors stop the line here instead of surfacing in review.
  9. result-type-shape det ✓ pass 180 ms
    Annotation: Failures must throw a typed DomainError rather than encode success-or-error in the result shape, so callers can't read a failure as a success.
  10. judge-score llm ✓ pass 9.4 s
    rubric 94/100
    Annotation: The one LLM-judged gate in this slice. It scores the filled test against the journey spec's rubric, and it only grades; it never edits the work.
  11. scenarios-pass det ✓ pass 41.7 s
    Annotation: The finished suite runs. The work item doesn't leave the station until it's green.
11 gates 9 pass 2 fail det = deterministic · llm = judged against a rubric

What this transcript does and doesn't show

Ask any vendor for their gate logs.