jason.woltje
193479b52d
Mosaic concepts pages now own the adapted content; source/license metadata under docs/reference/concepts. Adds ACT-1 agent-context planning capture, pinned concept test package + preparation utility, foundation observation notes (durability, evidence, federation, onboarding, workflow), and the #1495 consolidation assessment. TOOLS.md updated for the host-dev launcher.
64 lines
4.0 KiB
Markdown
64 lines
4.0 KiB
Markdown
# Mechanical coordination and recovery — owner discussion backlog
|
|
|
|
Date: 2026-09-06. Recorded by darkwing.
|
|
Status: captured owner direction and open design questions, not an implementation
|
|
charter, product selection or authorization to change the current inspector build.
|
|
|
|
Jason wants a continuously operating software factory with minimal user babysitting.
|
|
Mechanical status checks, action timeouts, stalled-session detection and other
|
|
failure indicators should support bounded recovery and escalation: restart an
|
|
orchestrator when appropriate, escalate agent stalls to an orchestrator, and involve
|
|
the user only when remediation requires owner authority or cannot safely proceed.
|
|
These workflows need attention during low-level development, not as a late UI layer.
|
|
|
|
## Questions to resolve in later design
|
|
|
|
1. n8n versus a custom mechanical workflow implementation: compare durable execution,
|
|
restart recovery, authority boundaries, idempotency/reconciliation, operational
|
|
complexity, observability and maintenance. No technology has been selected.
|
|
2. Kanban triggering: identify the authoritative work-state transition and component
|
|
allowed to admit/trigger work. Boards should project the same recorded work truth;
|
|
UI events, duplicate notifications and card movement cannot independently grant
|
|
execution authority or create competing task state.
|
|
3. Stall/failure definition: distinguish quiet but healthy work, long-running actions,
|
|
missing telemetry, blocked external dependencies, lost controller connections,
|
|
provider failures and actual dead processes. Define observations, thresholds,
|
|
ownership and false-positive controls for each state.
|
|
4. Continuity without state loss: bind recovery to durable goals, assignments,
|
|
action/WAL evidence and exact session/execution identities, not chat memory alone.
|
|
5. Recovery ladder: specify which checks, retries, restarts, Resume/Fresh operations
|
|
and escalations are preauthorized, by whom, within which scope and attempt limit.
|
|
Preserve other valid work and avoid restart storms or recovery loops.
|
|
6. Minimal owner remediation: distinguish routine recoverable faults from genuine
|
|
authority/safety decisions. Escalations should include diagnosis, attempted bounded
|
|
recovery, preserved evidence and a small actionable choice—not an unexplained
|
|
request for the user to investigate the whole system.
|
|
|
|
## Constraints to preserve
|
|
|
|
- A timeout or missing heartbeat is a signal, not proof of process death or absence
|
|
of effects. Fence stale controllers/workers and reconcile uncertain effects before
|
|
replacement; no blind replay or duplicate active execution.
|
|
- Restarting an orchestrator must not lose its outstanding obligations or confer
|
|
extra permissions. Mechanical coordination and model-based orchestration need
|
|
explicit ownership and independent recovery paths; neither is an unlimited role.
|
|
- Resume/Fresh may improve recoverability, but neither alone proves safe recovery.
|
|
Resume needs exact identity/history checks. Fresh must rebuild authorized work
|
|
context from durable records without silently importing old chat or abandoning work.
|
|
- Automatic recovery remains bounded by current intent, permissions, audit availability
|
|
and the accepted fail-safe stopping exception. Minimal babysitting is not permission
|
|
to guess around a safety refusal or silently change owner goals.
|
|
- Test orchestrator/worker crashes, delayed/lost/duplicate events, external outages,
|
|
restart during uncertain actions, sustained load and escalation/recovery loops.
|
|
Demonstrate both continued authorized work and preserved state/evidence.
|
|
|
|
Related: 2026-09-06_foundation-durability-observations.md and the accepted technical
|
|
map at 7345f330fc6bfae5aa1d896c78cfb7cbe62efbae.
|
|
|
|
## Current work boundary
|
|
|
|
This note preserves ideas for later discussion and workflow planning. It does not
|
|
select n8n, implement a daemon/watch, arm a timer, restart anything, investigate the
|
|
separate ~/.mosaic environment or retask Rocko/Filbert. FI-ROCKO-3 remains the frozen
|
|
offline synthetic inspector build. No new phase or independent goal loop is created.
|