Deployment layer

ASMP v0.1 is strong at inventory and discovery. It is not yet a full replacement for platform deployment config.

Two schemas today

ASMP service manifest (inventory + discovery)

name: email
capabilities:
  provides: [email.ingest, email.parse]
health:
  target: http://localhost:8787/email/healthz
lifecycle:
  launchd_label: com.reeves.email
repo: ~/repos-personal/reeves-email
display:
  section: reeves
  critical: true

Reeves apps.yaml (deployment)

email:
  app_key: reeves-email
  entrypoint: web.app:app
  port: 8770
  venv: .venv
  units:
    auto-sync:
      kind: job
      exec: ["reeves-email", "auto", "--limit", "100"]
      triggers:
        - interval_seconds: 300

reeves-daemon reads apps.yaml to provision processes, sockets, and scheduled units. It cannot read ASMP alone today — entrypoint and units are missing from v0.1.

Why not merge naively?

Approach	Problem
Put all 46 services in apps.yaml	Pollutes deployment config with knox, docker, claude-find
Delete apps.yaml, use ASMP only	Loses entrypoint, units, venv — breaks Reeves daemon
Keep both forever by hand	Process drift returns

Three paths forward (documented, not decided)

Option A: Extend ASMP schema (v0.2)

Add deployment block to service manifest:

deployment:
  entrypoint: web.app:app
  port: 8770
  venv: .venv
  units:
    auto-sync: { ... }

Reeves daemon reads ASMP for section: reeves services. Single source.

Pro: One file per service.
Con: Schema grows; non-Reeves services carry empty deployment blocks.

Option B: Generated view (recommended for transition)

ASMP remains inventory authority. Build tool emits apps.yaml from manifests where display.section == reeves:

~/.asmp/services/*.asmp.yaml  →  apps.yaml (generated, do not edit)

Pro: No schema explosion; clear ownership.
Con: Requires generator + discipline (“never hand-edit apps.yaml”).

Option C: Linked deployment mods

Inventory manifest + optional email.deployment.asmp.yaml mod attached via ASMP mod system.

Pro: Clean separation; mods pattern already in spec.
Con: Two files per app; more moving parts.

What ships in v0.1

• Inventory in ~/.asmp/services/
• Discovery via registry API + MCP
• lifecycle and run hints for future plist generation
• Not: full Reeves daemon migration

Agent registration docs must say

Wrong:

Add entry to apps.yaml, edit Caddyfile, reload.

Right:

Write ~/.asmp/services/{name}.asmp.yaml, POST to /services, let host provision.

Until deployment migrates, agents may need both for Reeves platform apps — but inventory registration happens in ASMP first.

Status

Decision: Open — ADR pending in spec repo.
Documentation first: this page. Implementation: after ADR + generator or schema v0.2.