dodil/erp-method

node_modules/.cache/erp-method/v0.1.20/erp/phase/deploy.md

Phases 6-8 · Deploy: provision, ship, verify with a real person

Produce a test copy and a live copy, a deploy from git push, and proof that the app reaches its data and a real person can sign in. This is the first phase that needs a DODIL login: if you are not signed in, ask the person to run dodil auth login. Back: dodil://erp/build.

Steps: provision (dev first; live only when the first release is approved)

  1. Bucket and pool per environment: dodil data bucket create acme-dev, dodil appid pool create acme-dev. Joining an existing system: reuse its bucket and pool.
  2. Roles: merge, never replace. dodil appid roles get acme-dev → merge yours → dodil appid roles set acme-dev --file @catalog.json. roles set replaces the whole catalogue.
  3. Sign-in that works: dodil appid settings set acme-dev --allow-signup=false --redirect-uris … listing EVERY app's callback (read the current list first) https://<app>-<org>-<port>.ignite.dodil.cloud/.dodil/auth/callback. Then create at least one user per role: dodil appid user create acme-dev <email> (no password: they set one through the reset flow).
  4. Service accounts: the staff app's has k3.editor scoped to the bucket (+ ignite.model-user if a brick calls Models). A public app (only if a brick issues links) gets its own, k3.editor only, no pool, public_invoke=true, and never migrates.
  5. Tables: erp-compose plan compose.yaml prints each app's environment; erp-compose migrate compose.yaml applies every brick's schema plus the platform's, once per release, test copy first.

Steps: deploy

  1. The staff app is deployed --user-pool <pool> WITH --allow-unauthenticated: the gateway injects identity when present and strips forged headers; the app's sign-in gate refuses every route without identity except /healthz and /.well-known/oauth-protected-resource. Keep it warm (--reserved 1) and turn on CIMD on the pool: Claude.ai allows ~10 s to discover a connector, a cold start took 12.3 s and the first connect failed (live, 2026-10-18, crm-demo).
  2. The sign-off check in CI (erp-platform v0.8.2; verify --all checks every signed process): a signoff job running erp-compose signoff verify --all (non-zero on unsigned, pending, DRIFT or NOT IMPLEMENTED; erp-platform README, "Sign-off in CI") and require_checks: [ci/signoff, …] under when: in .dodil/deploy.yaml, full names. dodil git ci verify, then git push: the forge runs .github/workflows/*.yml itself → the registry → CD from .dodil/deploy.yaml. There is no separate deploy command.

Steps: verify

  1. dodil ignite invoke acme-dev calls POST /, the self-check that opens the bucket with the app's own credential. A 401 on the public URL proves only that the gateway is up.
  2. A real person signs in, once per role. You never set passwords, so this is the customer's step; the module is not verified until it has happened.
  3. Their agent connects as them: Claude.ai registers itself and arrives pending: dodil appid client list acme-dev, then dodil appid client approve acme-dev <id>. A machine (a job, Claude Code) uses a service client instead; never a person's agent.
  4. Scenarios live against the dev deploy (erp-scenarios run … --live, test card).

Example (wire settings for any driver)

pg:   host=pg.uk-lon-1.dodil.io port=5432 dbname=acme-dev sslmode=require
bolt: bolt+s://bolt.uk-lon-1.dodil.io:7687          never prefer, never neo4j+s://

Done when

  • POST / self-check passes through dodil ignite invoke on dev, then live after "go live".
  • A person per role signed in; their agent was approved and sees only their rows.
  • A person's FIRST connect from Claude.ai works on a cold attempt (no retry), with the app at --reserved 1.

Next: dodil://erp/phase/operate