Skip to main content
Status: draft · ADR-42 · Filed 2026-05-02

​
ADR — Persona-daemon project attach lifecycle

​
Status

Draft

​
Context

Lafonda’s launcher/install lane needs a stable answer to where project bootstrap behavior lives and whether a daemon attaches to projects dynamically or only at create/bind time. Her SPEC-021 flag-disposition work depends on this because -install-deps and -activate-venv only migrate cleanly if there is a real daemon-owned project-attach boundary. Two models were on the table:
  1. persona×project-scoped daemon at create/bind time
  2. persona-scoped daemon with dynamic attach/detach across multiple projects
Dynamic attach/detach is more flexible, but it introduces more runtime state and expands v1 scope substantially. The install lane needs a simpler committed shape.

​
Decision

v1 uses a persona×project-scoped daemon model. Normative rules:
  1. A daemon is bound to one persona and one project for its live lifecycle.
  2. Project attach is a discrete lifecycle boundary, but in v1 it occurs at daemon create/start rather than as a later arbitrary dynamic attach operation.
  3. Detach happens only through wrap/archive/destroy lifecycle, not through free-floating project switching.
  4. Multi-project personas are out of scope for v1 unless/until a later SPEC introduces dynamic attach/detach semantics explicitly.
  5. Project-bootstrap concerns belong to daemon-owned attach-time behavior, not persistent launcher flags.
Flag-disposition consequence:
  • -autonomy remains a declarative launcher input.
  • -install-deps and -activate-venv migrate into daemon attach-time lifecycle behavior.

​
Consequences

  • Lafonda’s install lane can proceed against a fixed v1 topology.
  • SPEC-070 v0.2 can define attach-time behavior without pretending dynamic project switching already exists.
  • The daemon count for v1 scales as persona×project, not persona-only.
  • Dynamic multi-project personas are deliberately deferred instead of being smuggled into v1 by ambiguity.

​
Alternatives considered

​
1. Persona-scoped daemon with dynamic attach/detach in v1

Rejected for v1. More flexible, but adds runtime state, attach arbitration, and project-switch semantics beyond the scope of the current daemon deliverable.

​
2. No attach boundary at all; keep bootstrap logic on launcher flags

Rejected. Leaves project-bootstrap concerns on the launcher forever and blocks the AI-first end-to-end contract Lafonda flagged.

​
Cross-references

  • SPEC-070 v0.2
  • SPEC-021
  • Lafonda research PR #46 / commit 3dae620 / docs/research/daemon-launcher-matrix-2026-05-02.md
Last modified on May 3, 2026