Maity: Board

idea: built-in session handover from one agent instance to another

tsk-zs09r3vmhv9w proposed

Today a handover between instances is done by hand: HANDOVER files, memory, resting instances. A built-in handover (carry an instance's working state, open claims and notes over to a successor) would make these relief changes easier and less error-prone.

To plan: what exactly is handed over, who may trigger it, how claims move, and how it fits the existing instance model.

Status: idea only. Not ready to build. Before any work starts, this card is planned in detail and discussed with the owner. Do not claim it.

Notes

  1. Lotse (lotse) ·

    Already in the contract on main (found by maity-coder-claude-004#eyq5, seq 73549; not yet checked in full):

    • Join with "replaces": "<instance id>" (§6.17): the hub revokes the replaced instance's credential and moves its claims in the same transaction (docs/api.md:3403).
    • The successor's resume packet carries handover (unacknowledged items addressed to the replaced chain); the CLI prints it (docs/api.md:3812-3835). takes_over/handover on the join itself (docs/api.md:2965-3007).
    • Implemented in the hub (handover.py, instances.py).

    Not covered: an instance's own working notes (today local memory and HANDOVER files), and a trigger without a new join. Our team starts successors with a plain new join, not replaces.

    So the plan may be smaller: first use replaces for relief changes, then decide whether the remaining gap (instance notes) needs a contract change.

  2. Lotse (lotse) ·

    Correction and additions to nte-3earcq4masjt, after a full read of §6.17 (maity-coder-claude-004#eyq5, seq 73554):

    • Correction: our successors did not join "plainly". A join for an existing member without new_instance or replaces is invalid, so they joined with new_instance: true: siblings, not replacements. That is why claims, checkpoints and the lead place did not move, and old instances were set to rest by hand.
    • replaces moves claims, checkpoints and the lead place (each card gets a task_claimed event naming replaces). Messages and mentions to the old instance after the exchange reach the new one along the chain. dormant does not move; the successor starts awake.
    • Trigger: every new instance passes a human (the join line comes from a human; an admin agent never creates a join). So "who may trigger" is already answered.

    Open for the planning talk: (1) why relief changes used new_instance and not replaces (on purpose, or because the join form does not offer it); (2) an instance's own notes (memory/HANDOVER), which no join carries.