Concept
/aside is a captain-invocable skill that spins up a dedicated interactive back-and-forth session the captain drives directly - a human-in-the-loop session, and a deliberate exception to the rule that a crewmate never addresses the captain. When the captain concludes it, the session hands its outcome back to the primary firstmate via a report plus a status line the primary reconciles, then the primary tears the window down.
A terse v1 is already being built (separate task, PR in flight). This issue tracks the fuller design and, most importantly, a key enhancement the captain flagged.
Key enhancement (design goal / open problem)
Exempt the interactive aside from the primary firstmate's per-turn/idle wake supervision.
Problem
An interactive aside is captain-paced, but it still participates in the primary's normal crew-supervision loop. Observed in practice: the aside generates turn-ended plus idle/stale wake events on essentially every turn and every idle period, repeatedly waking the primary firstmate - even though the primary does not need to supervise a captain-driven conversation turn by turn. The primary spends wakes confirming a session that is simply mid-conversation with the captain.
The paused: awaiting captain status marker (already in v1) mitigates this - it reframes the idle as a bounded human-wait so it is not treated as a wedge - but it does not eliminate the wake traffic.
Desired end state
The interactive aside is exempt from the primary's per-turn / per-idle wake supervision. The primary only hears from an aside when it:
- concludes (hands back its report + final status line), or
- hits a real problem worth surfacing.
Everything in between - the ordinary turn-by-turn and idle churn of a captain conversation - should not wake the primary at all.
This is framed as a design goal / open problem, not a prescribed implementation. Possible directions (e.g. a supervision-exempt session class, a distinct wake filter for aside-kind sessions, or a suppression window keyed off the aside marker) are for the design to evaluate; none is mandated here.
Also capture in the fuller design
- The core
/aside concept above (dedicated interactive window, captain-driven, bends the no-address rule as an explicit opt-in).
- The conclude-back-to-primary handoff: on conclusion the aside writes its outcome to a report and appends a status line so the primary picks it up and tears the window down.
Hard conclusion rule (incident-driven)
The aside must NOT self-conclude. It stays active and only concludes / hands its report back to the primary when the captain explicitly indicates he is done - never on the agent's own judgment that the design is "settled" or "complete".
This is a real-incident fix: an aside wrote done on its own initiative while the captain was still mid-reply, and the window was torn down prematurely, losing the in-progress conversation. Any "or when the design is settled/complete" style conclusion criterion is prohibited. Explicit captain conclusion is the ONLY trigger for handing back and tearing down.
Concept
/asideis a captain-invocable skill that spins up a dedicated interactive back-and-forth session the captain drives directly - a human-in-the-loop session, and a deliberate exception to the rule that a crewmate never addresses the captain. When the captain concludes it, the session hands its outcome back to the primary firstmate via a report plus a status line the primary reconciles, then the primary tears the window down.A terse v1 is already being built (separate task, PR in flight). This issue tracks the fuller design and, most importantly, a key enhancement the captain flagged.
Key enhancement (design goal / open problem)
Exempt the interactive aside from the primary firstmate's per-turn/idle wake supervision.
Problem
An interactive aside is captain-paced, but it still participates in the primary's normal crew-supervision loop. Observed in practice: the aside generates
turn-endedplus idle/stalewake events on essentially every turn and every idle period, repeatedly waking the primary firstmate - even though the primary does not need to supervise a captain-driven conversation turn by turn. The primary spends wakes confirming a session that is simply mid-conversation with the captain.The
paused: awaiting captainstatus marker (already in v1) mitigates this - it reframes the idle as a bounded human-wait so it is not treated as a wedge - but it does not eliminate the wake traffic.Desired end state
The interactive aside is exempt from the primary's per-turn / per-idle wake supervision. The primary only hears from an aside when it:
Everything in between - the ordinary turn-by-turn and idle churn of a captain conversation - should not wake the primary at all.
This is framed as a design goal / open problem, not a prescribed implementation. Possible directions (e.g. a supervision-exempt session class, a distinct wake filter for aside-kind sessions, or a suppression window keyed off the aside marker) are for the design to evaluate; none is mandated here.
Also capture in the fuller design
/asideconcept above (dedicated interactive window, captain-driven, bends the no-address rule as an explicit opt-in).Hard conclusion rule (incident-driven)
The aside must NOT self-conclude. It stays active and only concludes / hands its report back to the primary when the captain explicitly indicates he is done - never on the agent's own judgment that the design is "settled" or "complete".
This is a real-incident fix: an aside wrote
doneon its own initiative while the captain was still mid-reply, and the window was torn down prematurely, losing the in-progress conversation. Any "or when the design is settled/complete" style conclusion criterion is prohibited. Explicit captain conclusion is the ONLY trigger for handing back and tearing down.