Manifest quality

A manifest can exist in ~/.asmp/services/ and still be discovery-invisible if it lacks capabilities.

Minimum for discovery

asmp: "0.1"
kind: service
name: my-service
description: "One line — what it does"
version: "1.0.0"
created_by: claude-code
owner: you

capabilities:
  provides:
    - mydomain.myaction   # required for service_find

health:
  method: http
  target: http://127.0.0.1:8080/health

endpoints:
  - protocol: http
    port: 8080
    visibility: loopback

Minimum for inventory (dashboard)

Add display metadata:

display:
  icon: "🔧"
  label: My Service
  section: tools
  critical: false
  url: http://localhost:8080/

logs:
  path: ~/.local/log/my-service.log

repo: ~/repos-personal/my-service

Capability naming

Use dot-separated namespaces:

email.ingest
email.classify
task.manage
tools.knox          # acceptable placeholder
process.supervise

Convention: {domain}.{action} or {domain}.{resource}.{action}.

If unsure, use tools.{name} until you know the real surface.

Field coverage (production baseline)

On a mature host, aim for:

Field	Target
name, description, display	100%
health	100% for running services
capabilities.provides	100% — discovery depends on this
endpoints	All HTTP services
lifecycle	All launchd-managed

Gap example: 24/46 with capabilities means half the fleet is invisible to service_find.

Inventory-only entries

Some services are monitored but not capability-discoverable (e.g. tailscale, docker). Still declare:

capabilities:
  provides: [infra.tailscale]

So agents get something instead of silence.

Validation (coming)

asmp validate ~/.asmp/services/my-service.asmp.yaml

Until CLI ships, POST to registry and read error messages.

Anti-patterns

Anti-pattern	Why bad
Manifest with no provides	service_find fails
Port in description, not in endpoints	Agents cannot connect
Duplicate name in two files	Registry overwrite
Hand-copy to dashboard YAML	Process drift

See Three layers — discovery requires intentional provides.