Files
command-center/agent/managed-skills/serverappconfigs-deploy-execution-context/SKILL.md
T
Frank 8af40c402b chore(agent): commit the machine tier and the doctrine text the checkout was already running
Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and
`merge --ff-only` refuses while tracked paths are dirty. Discard is not available here
(workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed.

- `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already
  byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new
  prose — the commit exists so the trunk merge can proceed.
- `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat
  owns (AGENTS.md § Live-sync tiers).

`ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the
only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the
inert all-zero AWS example id — and they appear inside the two skill pages that teach
that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged
gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal
dies with this landing. No `--no-verify` was used: the gate ran and its verdict is
recorded here.

Refs #61
2026-10-21 01:44:51 -07:00

2.3 KiB

name, description
name description
serverappconfigs-deploy-execution-context Run scripts/deploy.sh for serverAppConfigs from the correct checkout: must be a clean dev-side main branch, never a feature worktree, and how to get there when the session worktree sits on another branch.

Run scripts/deploy.sh from the correct checkout

deploy.sh hard-refuses outside a clean main checkout (FAIL: deploy.sh must run from the main branch., exit non-zero) — and this box has several serverAppConfigs checkouts.

The map (dev box, verified 2026-10-21)

  • Canonical dev main checkout: /home/blank/Projects/serverAppConfig — the ONLY place deploy.sh may run. It holds the main branch worktree (git refuses the same branch checked out twice, so session worktrees can never satisfy the gate).
  • ~/.omp/wt/wt-<...> session worktrees: often parked on unrelated feature branches with uncommitted work — never deploy from here; do not git checkout here (workspace policy blocks it in shared trees).
  • /tmp/wt-* build worktrees: correct place to edit/test/PR, wrong place to deploy (branch != main by design).

Procedure

cd /home/blank/Projects/serverAppConfig
git pull --ff-only origin main          # deployer must carry the merged commit
./scripts/deploy.sh <target> --service <svc>

Merge lands on origin/main first — deploy runs AFTER the PR is merged (ff-pull picks it up). Each invocation costs ~2 min (e2e gate ≈ 1 min + health gates); chaining several --service runs in one bash call is fine, but background it (| tail per service) so the harness doesn't stall the turn.

Gotchas

  • worktree add -b main /tmp/... fails (a branch named 'main' already exists / already used by worktree at /home/blank/Projects/serverAppConfig) — that IS the answer: don't mint a main clone, use the canonical path. Prune leftovers: git -C /home/blank/Projects/serverAppConfig worktree prune.
  • The remote runner updates its OWN checkout (embedded ff-only pull before dispatch), so shipping a brand-new service handler works: the remote gate is evaluated against freshly pulled code. Only the CLIENT gate (deploy.sh valid_service) can veto a first-ever deploy — see skill new-fleet-service-checklist.
  • Bare deploy.sh <target> = fleet-wide drain (restarts every lagging service marker). Always --service.