Typed systemd host-service ownership without shell lifecycle drift

• the repo depends on a host-managed Linux service that is already owned by systemd
• shell systemctl start, stop, or is-active glue is obscuring real service ownership
• ota should derive lifecycle from a declared unit instead of pretending the service is just another shell task

• it turns a repo pattern into something humans, CI, and agents can read the same way
• it makes the next command obvious instead of implied by README drift
• it keeps readiness, setup, and execution explainable in receipts and diagnostics

Use this when the repo's service truth is a systemd unit on the host and ota should own lifecycle and readiness directly.

The example keeps service ownership under manager.kind: host with a typed manager.host.kind: systemd lane and uses readiness.kind: systemd_active instead of endpoint or shell probes.

If you want ota to author this shape for you, start from ota assist declare-service --name <service> --manager host --host-unit <unit> --style systemd-active and then refine from there.

version: 1project:  name: systemd-host-service  description: Focused example for typed systemd host-service ownership  type: applicationexecution:  default_context: host  contexts:    host:      backend: native      requirements:        tools:          systemctl: "*"services:  redis:    manager:      kind: host      host:        kind: systemd        unit: redis.service        scope: system    readiness:      kind: systemd_active      interval: 2s      retries: 5      start_period: 1stasks:  verify:    command:      exe: redis-cli      args:        - ping    requires_services:      - redisworkflows:  default: host-redis  host-redis:    services:      required:        - redis    run:      task: verifymetadata:  ota:    minimum_version: "1.6.21"

Use manager.host.kind: systemd when ota should derive systemctl start, stop, and active-state checks from one declared unit instead of shell glue.

Use readiness.kind: systemd_active when unit state itself is the truthful readiness signal; keep endpoint-based tcp or http readiness only when the repo really needs application reachability as the gate.

Keep manager.start / manager.stop for other host owners; do not combine them with typed manager.host ownership on the same service.