[colosair]

JAM 1.6.0 answers to the same lifecycle words as ASC, so a person does not have to remember
which product uses which verb.

setup      make it usable for the first time
status     what is configured, what works, what is blocked
update     move to a newer published release
refresh    keep the version, re-converge what this build registered
uninstall  remove the product; the person's state stays
runtime    which build this machine actually runs

What changed

• jam status. The first place to ask what is going on. It is doctor's user-facing role
  under the shared name, and it does not reimplement the judgement: the same health gate and
  the same per-axis verdicts answer — credentials, project binding, runtime, registration,
  live toolset, Jira authentication, Jira project access. jam doctor keeps working and names
  its replacement.
• jam refresh. Keeps the version and re-registers what this build owns. What goes stale
  in JAM is a registration line; update is for when a newer release exists, refresh is for
  when the line drifted from the build that is already here. Its scope stops there — the
  project binding, ~/.jam/config.yaml, the credentials and every .jira-agent/project.yaml
  are outside it. jam refresh check and jam refresh plan change nothing.
• jam uninstall. Removes the MCP registrations JAM wrote and the global launcher when one
  is installed. It keeps ~/.jam in full — the project bindings, the runtime choice — and the
  credentials in the OS secret store. There is no purge: nothing yet needs a command that
  destroys those, and an irreversible one nobody asked for is worse than a missing one.
• Help is organised by what a person is doing — Lifecycle, Jira, Authentication, agent
  entry points — with jam serve named for what it is: the host's launch command, not
  something a person types.
• Nothing is removed before its replacement is verified, in refresh as in update, and a
  registration JAM could not read back is never reported as done.

What did not change

JAM has no Execution Mode. It is the Jira access layer: no session model, no approval path,
no guard. MANUAL/AUTO belongs to ASC, and a Jira write still travels ASC's decision path and
lands through jira_write_plan / jira_write_apply.

The two products share a vocabulary, not a release train. ASC 0.8.0 and JAM 1.6.0 are
independent; neither updates the other, and neither pins the other's version.

The Jira read/write safety contract is untouched. Writes are still plan-then-apply against
the bound project, still confirmed by reading the issue back, and a write JAM could not verify
is still never reported as done. Reads still carry meta.complete, meta.evidenceScope and
meta.limitations as they did.

Verification

npm run release:verify
  build           OK
  tests           510 passed | 15 skipped
  release:check   Release 1.6.0 is consistent across manifests, code and docs
  packed smoke    all checks passed

New coverage for this change is in packages/server/tests/unit/lifecycle.test.ts: refresh
leaves a bare entry alone, skips a host with no JAM entry, removes before re-registering, and
fails rather than claiming success when the read-back still shows the old pin; uninstall
touches no path under ~/.jam and runs no removal of the person's files.

Published dogfood has not run — that comes after publishing, in a fresh session.

🤖 Generated with Claude Code