Delivery Factory · Part 4

Delivery Factory · Part 4 · Conventions, Serve and Baseline

Conventions, serve and baseline: the project before the build

Three stages run before the pipeline builds or designs anything. conventions researches how this project does things. serve makes sure a preview answers. baseline captures what a component looks like now, so the end of the run has something to compare against. Repo: agentic-eds

Checked in README + code

Read in the agentic-eds README, pack.yaml, and the skills and scripts of these three stages. Source: agenticDraft/plugins, folder plugins/agentic-eds/. Paths are relative to that folder unless said otherwise.

The whole route, and where we are1200 × 627
DELIVERY FACTORY · PART 4 Fifteen steps. We are at conventions, serve and baseline. BEFORE THIS POST NEXT intake readiness extract conventions serve baseline prototype verify-design plan plan-gate implement verify lint publish-gate deliver conventions three subagents, run together: styles · markup · component reuse writes one file, and the plan reads it as its only source of conventions: design-conventions.md serve cleans up old drafts, then polls the preview URL before starting anything polls at 0 · 2 · 4 · 8 · 16 s any HTTP status is an answer serve-report.md baseline a script finds a page holding the component, never in drafts/ browser: render · capture 375, 768, 1440 · measure the component baseline-capture.json None of the three builds anything. They leave the project understood, answering and photographed.
The route has fifteen steps. The first three are behind us: the ticket was fetched, checked and its design read. These three look at the project itself. Four of the fifteen run only when the ticket asks for them. Baseline is one of them: it runs only when a component is named.

Each step runs as its own isolated agent and returns a short result block. The next post covers the browser plugin that baseline uses. This post covers what the three steps themselves do.

Conventions

How this project does things

The stage eds-conventions always runs. It needs no tracker, design or browser: everything it reads was already written by the stages before it.

Dispatched together. The three subagents are called in the same turn, because none of them depends on another's result. The stage waits for every dispatched one before it decides its own verdict.

One file for the plan. The stage writes design-conventions.md: one section per dispatched subagent, with its summary, and a final ## Exemplars section that is never empty. The plan stage reads this file as its only source of project conventions and does no research of its own. A finding that is not written here is lost to the rest of the run.

Its own words. Each subagent ends with a small outcome block (success, warning or failure). The stage writes its own result from them and never returns a subagent's outcome unchanged.

# design-conventions.md
## styles
<the subagent's summary, verbatim>
## markup
<the subagent's summary, verbatim>
## component reuse
<the subagent's summary, verbatim>
## Exemplars
blocks/<name>/
blocks/<name>/

Serve

Poll first, then start

The job of eds-serve is that something answers at the project's preview URL by the time it returns. It runs on every ticket.

  1. Clean up earlier runs' drafts: delete the drafts of items whose change is merged or closed, and stop the draft server once no recorded change is open. The result is written into the report but never changes this stage's verdict.
  2. Read commands.serve and paths.preview from .ai/project-config.yaml. No preview URL configured: fail. The stage never guesses one.
  3. poll-preview.sh against the URL. If something already answers, pass. Nothing is started, and the report says this stage did not start what is running.
  4. Nothing answered and a serve command is configured: start-serve.sh starts it, writing a log and the process id.
  5. Poll again on the ladder: five polls, at 0, 2, 4, 8 and 16 seconds, about thirty seconds in all.
  6. An answer before the ladder ends: pass. No answer: fail, naming this as a transient failure, with the process id and the log in the report.

Any HTTP status is an answer. A 404 or a 500 included. The question is whether the origin is bound, not whether one path exists. A preview path is configuration, and a poll that demanded a particular status would fail forever on a project whose configured path is not a served one.

Poll before starting. A server may already be up from an earlier run. Starting a second one against a bound port makes a process that dies on startup while the poll still succeeds against the first.

The server outlives the stage. It has to: every later stage that renders a page runs in a different isolated agent. The stage cleans up drafts, but nothing in the route stops the preview server. The report is the only record of the process that is left running, and the process id in it is the only handle.

Loopback needs the sandbox off. The default command sandbox denies connections to localhost every time, so the stage runs its three commands with the sandbox disabled, as the skill states, rather than trying sandboxed first.

Baseline

The before picture

eds-baseline runs only when the fact record names at least one component. It captures what each component looks like now, so the verify stage can compare before against after, not only after against the design.

  1. Resolve the browser plugin from the project config and read its operations: render, capture and measure. Any of them missing: fail.
  2. Take the component names from the fact record, or from the blocks/<name>/ paths the ticket names.
  3. find-baseline-target.py lists the pages git knows about and prints the first one that holds the component, as a page path and a URL. It never searches drafts/. The model adds no page the script did not print.
  4. render the page. capture it at 375, 768 and 1440 pixels. measure the selector .<component>.
  5. Write baseline-capture.json: the URL, the components, each width's screenshot path (or that width's failure) and the measurements as the browser plugin reported them.

Same widths later. 375, 768 and 1440 are the widths the verify stage uses for its own capture, so the two runs line up.

Content outside the checkout. If a project's authored content is mounted from an external source, the search can see nothing even when a page genuinely exists live. The stage does not reach outside the checkout, and says that nothing was found.

# baseline-capture.json, the fields
target URL
components captured
per width: screenshot path, or that width's failure
per selector: the browser plugin's measurement,
  unchanged, including found: false

Pass, warn, stop

Three stages, three sets of verdicts

Each stage ends with a result block: pass, warn or fail. Warn does not stop the route.

What it doesn't cover

The limits, as stated

From the skills and the pack's README.