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

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.

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.

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.

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.

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.

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.

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.

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