Pressure-testing Ota on Directus: structured pnpm hydration and honest workflow boundaries

Overview

Directus was a good bridge repo for Ota’s newer Node surfaces.

It sits in the space between “simple install and lint” repos and much heavier multi-service systems:

• large pnpm workspace
• real contributor lint and test surfaces
• heavier recursive build and unit-test paths
• an even heavier Docker-backed blackbox path

That makes it a strong governance test for where the default Ota path should stop.

What Directus proved

Directus proved that Ota’s newer contract surfaces can represent a mature contributor-readiness slice without pretending every repo-owned script belongs in the default path.

The important pieces are:

• lockfile-strict pnpm hydration as first-class setup
• a lean agent-safe default verify path
• explicit broader workflows for recursive unit tests and build
• a clearly separate Docker-backed blackbox workflow

That is a better shape than treating the whole repo as one undifferentiated “run checks” surface.

What changed in the contract

The setup lane now uses first-class pnpm hydration:

tasks:
  setup:
    prepare:
      kind: dependency_hydration
      medium: package_dependencies
      source:
        kind: node_package_manager
        cwd: .
        manager: pnpm
        mode: install
        frozen_lockfile: true

That means the contract owns:

• package-manager identity
• lockfile strictness
• hydration side effects
• network semantics

Instead of hiding all of that inside corepack pnpm install.

The default contributor path is intentionally lean:

tasks:
  verify:
    aggregate:
      tasks:
        - lint

And the workflows make the boundary explicit:

workflows:
  checks:
    setup:
      task: setup
    run:
      task: verify

  unit:
    setup:
      task: setup
    run:
      task: test

  build:
    setup:
      task: setup
    run:
      task: build

  blackbox:
    setup:
      task: setup
    run:
      task: test:blackbox

That split is the whole point.

Directus has broader real repo surfaces, but not all of them should be treated as the default safe lane for contributors or agents.

Why this mattered

Directus is a good example of a repo where the strongest contract is not the widest contract.

The root lint, recursive unit test surface, full build, and Docker-backed blackbox flow are all real.

But they do not carry the same cost, risk, or operational assumptions.

The mature contract says that plainly:

• checks is the lean contributor path
• unit is broader recursive test proof
• build is broader workspace proof
• blackbox is a heavy Docker-backed path outside the default agent-safe boundary

That is better governance than one broad default workflow that sounds complete but is less trustworthy.

Install truth also stays governed

The pressure branch keeps Ota install truth contract-owned:

• the contract bootstrap uses the current branch-install surface
• the CI workflow consumes repo-owned install truth through ota-run/setup
• the contract floor is aligned to the current 1.6.22 pressure lane

That matters because pressure repos should not split contract bootstrap truth from workflow install truth.

What the matrix proves

The green run for the Directus branch is #27534754506, completed on June 15, 2026.

That run is still enough to support the core note because it proved the contributor-readiness slice this branch claims:

• validation
• doctor
• task/workflow discovery
• native and container planning
• executable proof for the defined contributor-readiness path

That is enough to support the pressure slice this note documents.

Why this repo is weaker now

Directus was useful because it helped validate the more mature pnpm/Corepack modeling Ota ships today.

That also means its remaining pressure value is lower now.

The repo still tells a good story, but it is no longer one of the sharpest places to look for the next Ota platform gap.

That makes it a good reference fixture for Ota’s current pnpm/Corepack contract story.

Links

• Contract: directus ota.yaml
• Matrix workflow: test-ota-contract-matrix.yml
• Green matrix run: #27534754506

---

Originally post here: https://ota.run/blog/pressure-testing-ota-on-directus-2u6q

Comments

[Vinicius Pereira]

"the strongest contract is not the widest contract" is the line that's going to stick with me. the instinct on these systems is always to make the agent-safe surface as broad as possible so the agent can do more, but the trust comes from what the default lane refuses to touch. an agent that structurally can't reach the docker blackbox lane can't burn it at 5pm on a friday, the same way a narrow capability set is safer than a broad one you're constantly hoping nobody misuses.

the pnpm hydration part is the one i'd underline for anyone building this elsewhere. hydration is the classic stage that "usually works", so it lives hidden inside corepack pnpm install and nobody contracts it, and then the day it doesn't (lockfile drift, a network flake, the wrong pnpm resolving) is the longest debugging session in the repo. pulling package-manager identity, frozen-lockfile strictness and network semantics up into ota.yaml as a first-class step is the same discipline as refusing to let any stage silently assume the previous one succeeded. make the boring step observable and it stops eating afternoons.

one thing i'm curious about, since the boundaries are so clean at keeping the agent out by default: what does the crossing look like? when a contributor or agent legitimately needs blackbox, is the opt-in itself contracted and recorded, so you can later see who stepped outside the default-safe lanes and why? the honest boundary is great at containment, the interesting governance question feels like the audited exception.

[Bobai Kato Ota]

That’s exactly the right question.

Ota is already strongest at keeping the default-safe lane narrow and making heavier lanes explicit. What is still weaker is the crossing itself: why it happened, whether it was routine or exceptional, and the recorded trail around that step.

So yes, that’s a real next governance boundary, and I’ve already made a plan to strengthen Ota there. I appreciate the push.

How do you handle that today? When someone or an agent steps outside the default-safe lane, what do you most want captured first: the reason, the exact lane crossed, the approver, or the runtime evidence after it ran?

[Vinicius Pereira]

i'd capture the binding first: the exact lane crossed and who approved it, emitted by the boundary itself at the moment of crossing, as a record the crosser can't author. that's the one piece you can never reconstruct later. the reason and the runtime evidence can both be enriched after the fact, but if you didn't stamp which lane and which approver at the crossing, there's no anchor to hang any of it on.

the reason matters, but it's the crosser's narrative, so it's the part most likely to be self-serving and least likely to actually go missing (people are happy to explain themselves). the runtime evidence is the outcome, and it's only trustworthy if it points back at a specific crossing record instead of floating free. so the order i'd want is lane and approver first, captured synchronously by the system and immutable, then the reason attached by the human, then the runtime evidence attached after it ran.

the test i'd hold it to is the same one as the grant itself: the crossing record has to be a first-class object the boundary writes, not a line the crosser writes about themselves. the moment the person stepping outside is also the person describing the step, you have a diary, not an audit. so make routine crossings record that binding cheaply and automatically so nobody routes around it, and make exceptional ones force the approver and reason out loud. cheap for the common case, loud for the rare one, and un-authorable by the crosser in both.