Pressure-testing Ota on OSF.io: staged Compose control and bounded Postgres proof

OSF.io is not a one-command Docker project. Its documented local path has a meaningful order: materialize overrides, run requirements containers, start backing services, start asset and supporting services, then start the app stack.

That is valuable pressure for Ota because an opaque docker compose up task loses the order, the service ownership, and the distinction between routine verification and deliberate local maintenance.

The refreshed pressure branch runs released Ota v1.6.25. It proves the complete contract and dry-run surface across Ubuntu, macOS, and Windows, then performs real runtime proof only for the explicit local-postgres workflow on Ubuntu. It does not claim that the full OSF application stack became ready.

The pressure contract lives on a fork while it is under review. It follows OSF's documented Docker Compose development path without turning that path into unstructured shell glue.

Ordered Compose Input And Image Hydration

The override file is materialized explicitly, and the ordered Compose file stack is part of image hydration truth:

images:pull:  prepare:    kind: dependency_hydration    medium: container_images    source:      kind: docker_compose      cwd: .      files:        - docker-compose.yml        - docker-compose.override.yml  effects:    network: true    network_kind: container_image_hydration

This is stronger than a hand-written docker compose pull: the exact Compose input stack and the fact that this lane reaches the network are contract truth.

Staged Service Ownership

The contract preserves the documented topology instead of pretending every service belongs to one undifferentiated startup command:

core:up:  compose:    kind: up    detach: true    services:      - elasticsearch      - postgres      - mongo      - rabbitmq

Later tasks own requirements containers, asset watchers, supporting services, and the app services separately. local-docker is the declared workflow for that full staged path; its current matrix coverage is admission and dry-run coverage, not a claim that every OSF container started.

Destructive Maintenance Is Explicit

The focused runtime lane is deliberately smaller. It starts the local Postgres Compose service and names volume reset as a destructive maintenance task:

postgres:reset:  action:    kind: reset_compose_service_volume    service: postgres    volume: osfio_postgres_data_vol    compose:      files:        - docker-compose.yml        - docker-compose.override.yml      project_name: osfio

This is not a hidden cleanup recipe. The contract exposes the target service, volume, Compose inputs, and external Docker/Postgres effects before execution.

The updated matrix installs Ota from the contract, verifies the exact release before it evaluates the contract, and retains JSON, topology, receipt, and proof evidence from successful as well as failed runs.

The green matrix run installed ota v1.6.25 at commit a3e9f98f3. It exercised:

• ota validate, Doctor, task discovery, safe-task discovery, workflow discovery, and execution topology;
• every public task and both workflows in dry-run mode;
• the real local-postgres runtime proof before and after postgres:reset on Ubuntu;
• contract and dry-run compatibility on macOS and Windows;
• retained evidence artifacts for all three lanes.

The runtime proof is intentionally qualified. Both Ubuntu proof records report passed_with_unproven_boundaries with broader_repo_completion_not_proved. Their summary remains risky because the selected path explicitly mutates Docker and Postgres. A successful local Postgres readiness result is not permission to read it as repository-wide readiness or as application correctness.

The contract uses native host orchestration to call Docker Compose. That is not Ota container-mode coverage, and the matrix does not claim it is.

The pressure result is useful precisely because it leaves important things uncollapsed:

• local-docker has a governed staged topology and full dry-run coverage, but no full-stack hosted runtime proof;
• PostgreSQL readiness is not proof of OSF web, API, worker, asset, migration, or third-party-service behavior;
• Docker engine configuration, daemon availability, image registry access, and host resource capacity remain provider and host concerns;
• the README's pre-asset node_modules cleanup remains repo-owned setup guidance, not an implicit Ota mutation;
• no result here governs the wider OSF.io repository, deployment workflows, or production environment.

This is the appropriate boundary for an external pressure repository: govern the selected path deeply, preserve the rest as explicit scope, and refuse the temptation to convert a green service probe into a broader claim.

OSF.io confirms that Compose support is not merely up -d.

For serious repositories, the contract needs to express ordered files, image hydration, one-shot containers, staged detached services, readiness, and destructive state transitions. Ota can own those execution decisions while keeping the claims on the wire narrow enough to be trusted.

• Pressure contract: osf.io ota.yaml
• Matrix workflow: test-ota-contract-matrix.yml
• Evidence: run 30624808234
• Upstream project: CenterForOpenScience/osf.io