feat(joe): explicit repo maintenance with evidence-based health

[alari76]

Slices 3–4 of docs/JOE-REPO-COLLABORATION-MAINTENANCE-SPEC.md (§6–§9, §11). Stacked on #702.

Model (maintenance_plans, maintenance_responsibilities, maintenance_activity in runs.db)

• A repo is maintained only once the user enables its plan. Nothing is inferred from sessions, tasks, memory or existing automations.
• Responsibilities link to existing repo automations that provide their checks. There is no second scheduler.
• Each responsibility has a scope, a response policy (notify / propose work / investigate / implement), a task limit, and a list of changes that always need a decision.

Health

• Health comes from the linked automations' health (feat(joe): first-class tools to manage repo automations #698). Plan labels: Joe maintaining / Maintenance starting / Maintenance needs attention / Maintenance paused / Not maintained.
• Missing, stale, held, disabled or failing checks never count as healthy.
• An enabled plan with no enabled responsibilities needs attention.
• Disabling or removing a linked automation returns affectedResponsibilities and records a coverage entry.

Authority (enforced server-side)

• Joe can propose responsibilities and pause. Only the user can enable, resume, turn off, or change accepted responsibilities.
• Pause and off are an engine dispatch gate for automations adopted into the plan. The automations' own enabled setting is never rewritten, so resume restores them as they were. Independent automations are unaffected; "Run independently" releases one.
• Tasks with a responsibilityId require an enabled plan and respect the task limit. Under a notify policy they can't be created; under propose, only the user can start them.

Observation → bounded action

• Each finished run of a linked automation is recorded once (deduped by run id) as Check completed / No changes / Check failed.
• Joe then gets a Maintenance Check notification with the report, the policy text and the limits.
• Joe records the outcome with record_maintenance_activity.

Joe tools: list_maintenance, get_maintenance_plan, propose_maintenance_responsibility, remove_maintenance_responsibility, pause_maintenance, record_maintenance_activity. create_task also accepts responsibilityId. Instructions are template v12, with a new "Maintaining Repos" section.

UI

• Maintenance indicator under each maintained repo in the sidebar, e.g. "Joe maintaining · 2 running · 1 needs you".
• Maintenance view at /maintenance/<repo>:
  • Responsibilities, each check's status, last success and next run.
  • Managed automations.
  • Current actions and recent activity.
  • Permissions.
  • Review & enable dialog with a per-automation adopt choice.
• The Tasks overview lists maintained and paused repos.
• The Automations list marks adopted automations.
• Each session's menu has Hand over to Joe / Take back control.

Verification

• New tests: maintenance-service.test.ts (13), dispatch-gate tests, MaintenanceView.test.tsx.
• Full suite: 216 files / 4080 tests pass. Lint and typecheck are clean.
• Ran an isolated instance in headless Chromium:
  • Joe proposed a responsibility over REST; Joe's own enable attempt was refused (403).
  • The user reviewed and enabled in the UI. The sidebar showed "Maintenance starting" (no run yet) and the automation was marked managed.
  • The Tasks overview showed the plan state.

🤖 Generated with Claude Code