4-legacy

Scenario 4 — an old stream + an old worker: the events were already right

Existing streams are full of keyed context-added events — and with key resurrected as THE addressing mechanism, they are not a legacy vocabulary needing a mapping: they are literally today's everyday event. @30 lands un-sent and pre-conversation (joins the standing document), @55 lands after a send (temporal, supersedes) — the covered/uncovered behavior the old fold had is the behavior we re-derived from first principles. There are NO special keys (@80): an old worker's whole-prompt write to agent/system-prompt is just a section with an arbitrary key — it renders at its moment as a plain section in the timeline, the standing document above it untouched (the accepted doubling in that rare mix is closed by a repo sweep, not by kernel key-smarts).

<details> <summary>events</summary>

id: legacy
events:
  - off: 10
    t: 0ms
    type: agents/context-added
    payload:
      role: system
      sections:
        - key: identity
          content: >-
            You are a general-purpose agent on the iterate platform. You act by writing codemode
            scripts against the itx surface…
        - key: output-formatting
          content: >-
            Respond with ```ts fences; ONE codemode script per reply; markdown outside the fence
            is your visible chat message…
        - key: summary-instruction
          content: >-
            AGENT SUMMARY (mandatory) — append alongside your work: itx.agent.append({ type:
            "…agent/summary-updated", payload: { title, activity } })…
        - key: workspace-and-repo
          content: >-
            Your workspace mounts every project repo at /repos/**; commits land straight on main
            and redeploy the project worker…
        - key: find-working-code
          content: >-
            FIRST MOVE for an unfamiliar API: await itx.docs.search({ q: "several related words"
            }) — working examples, type declarations…
        - key: capability-tour
          content: >-
            One annotated tour script of the itx surface (chat, repo, workspaces, agents,
            scheduler, integrations…)…
        - key: shape-of-work
          content: >-
            Do the work in scripts; end your turn by returning no value; results drive your next
            turn as developer context…
        - key: other-agents
          content: >-
            Delegate explicitly: const child = itx.agents.get('researcher'); await child.create();
            await child.message(task)…
        - key: files
          content: >-
            Attachments ride refs; oversized script results spill to workspace files the next
            script reads…
        - key: gotchas
          content: >-
            On a brand-new project the config repo may still be seeding — retry shortly instead of
            treating it as fatal…
    note: >-
      birth batch as in scenario 1: ten keyed events (@10–19), one per section, one atomic append
  - off: 30
    t: 2.2s
    type: agents/context-added
    payload:
      role: system
      key: config/agents-md
      content: Project AGENTS.md v1 (keyed add)…
    note: >-
      un-sent and pre-conversation → joins the standing document, exactly like scenario 1's birth
      reaction
  - off: 35
    t: 3.0s
    type: agents/context-added
    payload:
      role: user
      content: what does this project do?
      actor:
        type: user
        origin: web
  - off: 36
    t: 3.0s
    type: agent/llm-request-requested
    payload:
      model: openai/gpt-5.6-terra
      contractVersion: "7.0.0"
    note: a send — everything above is now sent
  - off: 37
    t: 5.4s
    type: agents/context-added
    payload:
      role: assistant
      content: |-
        It's the demo project — a dashboard at /projects/demo, deployed on merge to main.
        <codemode status="Idle">return</codemode>
      llmRequestOffset: 36
  - off: 38
    t: 5.4s
    type: agent/llm-request-settled
    payload:
      requestOffset: 36
      result:
        status: succeeded
        text: |-
          It's the demo project — a dashboard at /projects/demo, deployed on merge to main.
          <codemode status="Idle">return</codemode>
  - off: 55
    t: 9m 18s
    type: agents/context-added
    payload:
      role: system
      key: config/agents-md
      content: Project AGENTS.md v2 (keyed add after a send)…
    note: >-
      sent → temporal append with supersedes: same rule as scenario 2
  - off: 80
    t: 14m 2s
    type: agents/context-added
    payload:
      role: system
      key: agent/system-prompt
      content: <the old worker's entire forked prompt, one 4,000-token blob>
    note: >-
      no special keys: the whole-prompt write is just a section with an arbitrary key — it renders
      at its moment in the timeline, alongside whatever else stands
  - off: 81
    t: 14m 30s
    type: agents/context-added
    payload:
      role: user
      content: quick sanity check — you still there?
      actor:
        type: user
        origin: web
  - off: 82
    t: 14m 30s
    type: agent/llm-request-requested
    payload:
      model: openai/gpt-5.6-terra
      contractVersion: "7.0.0"
    note: >-
      the request that carries both keyed adds — supersession and the whole-prompt blob, plain
      sections both

- request: "@82"
  find: 'supersedes="@30"'
  comment: "the @55 re-add — sent, so it supersedes at the tail: same rule as scenario 2"
- request: "@82"
  find: '<section key="agent/system-prompt">'
  comment: "the old worker's whole-prompt write: an arbitrary key like any other, rendered at its moment — no key is special to the fold"

</details>

<details> <summary>request @36</summary>

model: openai/gpt-5.6-terra
messages:
  - role: system
    content: "AGENT_CONTEXT_PROTOCOL_PROMPT — role semantics and trust rules (system items are durable instructions; never elevate