Pressure-testing Ota on Backstage: repo-managed tool probes, Yarn 4 hydration, and Docker-backed contributor proof

Backstage mattered because it pressured a narrow but very real contributor slice instead of a toy starter:

• Yarn 4 workspace hydration
• root docs and config verification
• Docker-managed dependency services
• one real local contributor runtime
• one standalone repo-managed CLI acquired from a release asset

That last point is what made the repo especially useful.

Backstage did not mainly expose a contract-shape weakness. It exposed an Ota execution-truth gap: after Ota had already provisioned a repo-managed release-asset tool correctly, later probe logic could still fail to execute that binary reliably from its repo-managed path.

That is exactly the kind of split-brain pressure a readiness system should survive.

Backstage is not just "run one package script."

Even this narrow contract slice has several different truths that need to stay honest at the same time:

• package hydration through Yarn 4, not ad hoc install shell
• finite verification through repo-root commands
• Docker-managed backing services for local development
• a long-running application surface exposed on port 3000
• a standalone docs-quality tool, vale, that is not assumed to exist on the host

That combination is valuable because it punishes a shallow execution model quickly.

If Ota can only say "a tool is required" but then loses track of the exact binary path it just provisioned, the product boundary is still too weak.

1. repo-managed tool ownership was stronger than probe truth

The contract already owned vale cleanly:

tools:  vale:    version: "3.15.1"    acquisition:      provider: release_asset

That was the right contract shape.

The problem was deeper in Ota. During verification proof, Ota had already materialized the binary under its repo-managed source-managed tool path, but later probe logic still treated that path too loosely and failed with an execution-level "No such file or directory" error.

That was not a Backstage contract bug.

It was an Ota gap between:

• provisioning truth
• doctor/probe truth
• later workflow execution truth

Backstage exposed that split clearly.

2. narrow contributor proof still needs real runtime ownership

This repo did not need Ota to model all of Backstage.

The right pressure slice was smaller and more honest:

• hydrate the root workspace
• verify docs and merged config
• prove the local contributor runtime against Docker-managed dependencies

That runtime path is explicit:

dev:  env:    BACKSTAGE_ENV: docker  launch:    kind: command    exe: yarn    args:      - start

and its service ownership stays explicit too:

services:  postgres:    manager:      kind: compose      file: docker-compose.deps.yml  redis:    manager:      kind: compose      file: docker-compose.deps.yml  opensearch:    manager:      kind: compose      file: docker-compose.deps.yml

That matters because Backstage is a good example of Ota governing a truthful local-development runtime without pretending the root contract has to own every repo subsystem at once.

3. standalone CLI ownership matters even in Node-first repos

Backstage is mostly a Node repo in this slice, but the pressure failure was not from Node.

It came from a standalone tool outside the package-manager lane.

That is important product pressure because mature repos regularly mix:

• toolchain-owned dependency hydration
• standalone CLI acquisition
• finite verification
• long-running runtime proof

If Ota only behaves well when everything stays inside the package manager, it is not yet governing real repositories.

Backstage forced a real Ota fix, not a repo-local workaround.

repo-managed relative binary execution had to resolve against the repo working directory

The repo-managed binary path for source-managed tools is relative to the repository. Ota's later probe and command-execution path needed to resolve that path against the repo working directory before execution.

Without that, Ota could provision a binary correctly and still fail to execute it afterward.

That is not acceptable execution truth.

doctor/probe logic had to prefer repo-owned source-managed tool paths consistently

The second part of the fix was governance and diagnosis alignment.

When a tool is repo-owned through source-managed acquisition, doctor and version probing need to prefer that exact owned path instead of sliding back toward weaker fallback behavior.

Backstage made that boundary concrete.

The right product behavior is:

• Ota provisions the binary
• Ota probes the same owned binary
• Ota executes the same owned binary
• doctor and workflow proof agree on the same truth

That is the bar this repo forced Ota to meet.

The final contract is strong mainly because it stayed narrow and explicit.

Yarn hydration is contract-owned:

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

Verification is aggregate-owned instead of opaque shell:

verify:  aggregate:    tasks:      - lint:docs      - config:check

And the runtime claim stays separated as a real workflow:

app:  intent: local_development  setup:    task: setup  run:    task: dev  readiness:    surfaces:      - site

That is the right shape for this repo.

The contract did not need to widen around the bug. Ota needed to become more truthful underneath the contract.

The green Backstage matrix now proves more than contract parsing:

• ota validate
• ota doctor
• ota tasks --use
• ota tasks --safe --use
• workflow-specific task discovery for verify and app
• dry-run for finite verification and workflow execution
• real finite verification execution on Ubuntu
• real runtime proof for the Docker-backed contributor workflow on Ubuntu
• macOS and Windows contract and dry-run coverage for the same contract slice

That is the right bar for this repo.

Ubuntu does the real runtime proof. macOS and Windows still matter because they pressure the same contract truth, bootstrap flow, and acquisition behavior across the advertised OS lanes.

Backstage proved an important product point:

structured contract ownership is not enough if later execution and diagnosis surfaces stop using the same owned path.

That is the difference between:

• a schema that describes tools
• and a readiness system that actually governs them

After this pressure pass, Ota is stronger in the important way:

• dependency hydration stayed first-class
• standalone CLI acquisition stayed first-class
• Docker-backed contributor runtime stayed explicit
• and repo-managed tool probing now matches the acquisition truth Ota already claimed to own

That is exactly the kind of pressure a real platform repo should apply.

• Repo: backstage/backstage
• Pressure branch: bobaikato/backstage tree bobai/backstage-ota-pressure
• Contract: bobaikato/backstage ota.yaml
• Green matrix: GitHub Actions run 27987721015