Recommended next

Typical signals

Node app plus Go service
build and service-test remain separate
runtime checks keep both sides honest

Why it matters

it turns a repo pattern into something humans, CI, and agents can read the same way
it makes the next command obvious instead of implied by README drift
it keeps readiness, setup, and execution explainable in receipts and diagnostics

Example contract

This example keeps the frontend and backend visible in the contract so a change in one path cannot silently hide the other.

ota.yamlyaml

version: 1project:  name: fullstack-node-go  description: Example contract for a Node application with a Go service  type: applicationexecution:  preferred: native  supported:    - nativetoolchains:  node:    version: "22"    fulfillment:      source: corepack      mode: run  go:    version: "1.24"tools:  npm: 10.8.2env:  vars:    OTA_SERVICE_ENV:      default: local      allowed:        - local        - citasks:  setup:    internal: true    description: Install application dependencies    category: setup    command:      exe: npm      args:        - install    safe_for_agent: true  build:    description: Build the app bundle    category: build    command:      exe: npm      args:        - run        - build    depends_on:      - setup  service-test:    description: Run the Go service tests    category: test    command:      exe: go      args:        - test        - ./...checks:  - name: repo-config-valid    kind: precondition    severity: error    run: ./scripts/validate-config.shagent:  entrypoint: setup  default_task: service-test  safe_tasks:    - setup    - service-test  verify_after_changes:    - service-test  writable_paths:    - src    - services    - docs  protected_paths:    - ota.yaml  notes: |    Use `ota run service-test` after application changes.    Use `ota run build` and `ota run test` to keep the Node and Go paths in sync through the contract.