Fieldtrip — Dev Board

Engineering operating board

How an idea becomes a reviewed, versioned feature, fitted to the production line and put into service for the content pipeline.

GPI pipeline in this case

FT ticketbranchcommitsPR (checks + review)squash-merge into maindeploy

Factory dashboard

Snapshot · 18 Sep 2026, 14:52 UTC

Rail ready
No blockers
Client main
613647b · 18 Sep 2026
Attested by the rail
613647b · 18 Sep 2026
Last factory change
886e0d8 · 17 Sep 2026
Open FT issues
82

of 132 work orders

Work-order funnel

132 work orders · bars show share of all work orders

Backlog

34

Todo

21

Ready for Dev

2

In Progress

4

In Review

21

Done

50

Recent rail activity

Last 14 days · phase bars relative to the busiest phase

Issues touched

38

Distinct work orders in the window

awaiting-deploy

1102

failure

430

preflight

358

poll

115

comment

58

gh

28

Last event: 18 Sep 2026, 14:49

Claims in flight

Active claims

5

Work orders currently held by the rail

  • FT-33 · 8beb71a

    Since 10 Sep 2026, 19:55

  • FT-35 · a56a33e

    Since 10 Sep 2026, 20:21

  • FT-34 · 3eaf9cd

    Since 10 Sep 2026, 20:34

  • FT-65 · 43e0c3e

    Since 13 Sep 2026, 16:40

  • FT-121 · 89b2914

    Since 18 Sep 2026, 13:42

Recent merges

Last 14 days · commits on client main

Landed on client main

256

Touched the factory

93

Subset of landed commits; may also touch the production line

  • 613647b · Define validated feedback envelope and retry identity (#98)

    18 Sep 2026 · brousso

  • 89b2914 · FT-65: Gate runtime sites and isolate delivery accounting (#100)

    18 Sep 2026 · brousso

  • 2310d89 · Close the dead gutter beside the sidebar (#121)

    17 Sep 2026 · brousso

  • 7e4302b · FT-62: Connect Jake’s rich articles and private Sanity publishing (#119)

    17 Sep 2026 · David-mo

  • 886e0d8 · Keep the queue moving: resume on restart, bound visuals, wait out rate limits (#118)

    17 Sep 2026 · David-mo

  • 9b7acc7 · Listicles: list first, two affiliates max, no disclosures, linked words; matrix redesign (#117)

    17 Sep 2026 · David-mo

01

The line — one work order, end to end

Follow 01–07 down the page.
Original map: Read left to right. Arrows are handoffs, not all automatic.

Existing step01

Linear / FT-N

The ticket

  • Outcome plus acceptance criteria, written before any branch exists
  • One accountable owner, one acting agent
  • Blocked-on and bay recorded on the issue itself
  • Fed by triaged feedback (FT-67).

the work order posted on the shop wall

Existing step02

JP's agents · orchestrator

Claim, then branch

  • Guarded claim on the issue, then scope
  • Branch cut from a freshly fetched main, never a stale local ref
  • Job ticket compiled from the acceptance criteria
  • The scheduler dispatches; the guards are what stop it.

the floor supervisor assigns the bay, the parts and the deadline

Existing step03

Two lanes

Commits in a worktree

  • One issue, one worktree: its own checkout of the repo
  • Refused if the tree is dirty or already claimed
  • Small reviewable commits, not one drop at the end
  • Two lanes, same repo, same shared conventions.

two workshops, each with its own bays, drawing on the same common stores

Existing step04

CI + critic

Checks and review

  • An independent critic reads the diff, not the builder's reasoning
  • Required checks run on the PR: tests, lint, build
  • Defects go back to the worktree as another commit
  • A green check is not approval to deploy.

the inspection bay, with its own gauges

Existing step05

FT-98 / Render

PR preview environment

FT-98 · Done

  • One shareable preview URL per pull request
  • Built by the same Dockerfile as production
  • Isolated non-production data, worker off
  • Previews inherit the seed's plan: that line is the only cost lever.

a pilot line is a copy of the real line; a bench is one person's workbench

Touches the live line · human gate06

GitHub / main

Squash-merge into main

  • Branch rebased on current main, PR reviewed and approved
  • Required approvals plus green required checks
  • Squash-merge, so main keeps one commit per issue
  • Merged is not released: main can sit ahead of production.

the new part is fitted into the main production line

Touches the live line · human gate07

Render / mise en service

Deploy

  • Attestation, merge and deploy are three distinct steps
  • Runbook: pause, drain jobs to zero, back up, deploy the exact SHA, /healthz, resume
  • A human confirms the deploy, then the issue moves to Done
  • Auto-deploy is off: someone chooses the commit that ships.

mise en service: the upgraded line is switched on to a written procedure

02

The control room — who decides, and what JC actually is

People decide outcomes. JC is JP's agent crew, and the three roles below are hats it wears, not three always-on services. Status follows evidence, and the evidence comes back to the ticket.

People and agreements

Human authority

JP + Dave

  • Priorities · scope · exceptions
  • Named review and commissioning approvals
  • Their agents execute their work.

the plant owners: no line goes into service unsigned

People and agreements

Linear / the ledger

Evidence closes the issue

  • A callback to Linear closes the work, not a status meeting.
  • Issue, PR, checks, merge SHA, deployed SHA.
  • Done means deployed, not merged.

the signed inspection sheet, not a word in the hallway

People and agreements

JP's agents · role 1

Product manager

  • Clarify, dedupe, split, prioritize
  • Write the acceptance criteria before the branch exists
  • Cross-team planning is not yet proven.

writes the job ticket before any fabrication

People and agreements

JP's agents · role 2

Engineering orchestrator

  • Claim, scope, fetch main, cut the branch, open the worktree
  • Compiles the job ticket, then tracks the PR
  • Never commits into the other lane's branches.

assigns the bay, the parts and the deadline

People and agreements

JP's agents · role 3

QA and review coordinator

  • Independent critic plus required checks plus acceptance criteria
  • Returns defects as commits on the same branch
  • Hands off review-ready PRs only.

the gauges belong to the inspection bay

03

Two workshops, one set of stores and jigs

A workshop is a crew and its lane. A bay is one job in its own fresh checkout of the line, refused if it is dirty or shared.

Existing step

JP's lane (JP + his agents)

Builder and independent critic

  • Eligible Ready for Dev issue, guarded claim, compiled job ticket
  • Fetch main, cut a branch, commit in a worktree, run the checks
  • Critic returns defects. Not every FT issue opens a branch.

workshop 1: own bays and own tools, the same common stores and jigs as workshop 2

People and agreements

What makes two crews agree

Conventions, then checks

  • Conventions shape the change as it is written: shared AGENTS.md, the job ticket, acceptance criteria agreed up front.
  • Checks measure it after: tests, CI, the critic's read of the diff.

a jig makes a good part repeatable across crews; a gauge only tells you once it is cut

Existing step

Dave's lane

Dave and his coding agents

  • Reads Linear and the shared AGENTS.md before starting
  • Own branch, own worktree, own tests and review
  • Shared files and merge order get coordinated through FT-101.

workshop 2: different crew, the same common stores and jigs, one shared plant floor

Serial numbers

Illustrative IDs, not current releases.

  1. main @ A
  2. branch B, commits
  3. PR B: preview + checks
  4. squash-merge C into main
  5. C deployed

If main moves or the branch changes: rebase, re-run the checks, refresh the review and the preview, then reconsider the merge.

the serial number on the part, on the test sheet and on the line in service all have to match

04

Model, related work and the current gap

Existing step

The mental model

We build the line, we do not ship crates

  • GPI is the plant. What we build and deploy is the production line itself.
  • The line is what runs; what the line produces reaches the client's blog platform.

lane = a crew and its branches · worktree = one issue in its own checkout · local = one person's machine · repo = the shared source · conventions shape the change · checks measure it · preview = a copy of the line for one PR

Existing step

Related / FT-79

UI foundation

FT-79 · Done

  • Land the Fieldtrip UI first.
  • Everything later bolts to it.

the chassis of the line

Existing step

Related / FT-67

Feedback intake

FT-67 · Done

  • Agree the destination + contract.
  • Capture, routing, triage.

the returns desk writes new work orders

Current gap

Current gap / FT-108

Nothing watches the line

FT-108 · Backlog

  • /healthz runs once at commissioning.
  • After that there is no continuous watch and no alarm console.

a check at start-up is not an instrument panel