vh/ratatoskr
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Refresh Worldtree spec pin: v0.19.0 → v0.22.1 #9

New Issue
Closed
opened 2026-05-23 14:24:45 -07:00 by vh · 1 comment
vh commented 2026-05-23 14:24:45 -07:00
Owner
Copy Link
Copy Source

Context

Our vendored Worldtree Conversation API spec pin is at v0.19.0 (commit 55101e909abcd2219833266b6f905c5bc956e0f0). Worldtree shipped v0.20.0, v0.21.0, and v0.22.x since (current is v0.22.1) per worldtree-dev's 2026-05-23 reply (althing thread 01KSBARG2B8M8C82H6AJGJWX1B).

What changed between v0.19.0 and v0.22.1 (consumer-relevant)

  • v0.20.0 (#185): end_user_id became the partition key for long-term memory + persona/valence state.
  • v0.21.0 (#189): Phase 2.1 added optional memory_context: list[dict] field to POST /sessions/{id}/messages; appended to per-turn system prompt as [MEMORY:DATA ...] blocks.
  • v0.22.0 (#197): ContextPromotion + STM tier removal; the [MEMORY:DATA] envelope was strengthened.
  • v0.22.1: current head (point-fix on top of v0.22.0).

None of these break ratatoskr's existing surface — POST /sessions, POST /sessions/{id}/messages SSE, and POST /sessions/.../turns/{tid}/cancel are stable.

What's needed

  1. Re-vendor docs/conversation-api-spec.md from ~/development/Worldtree/docs/conversation-api-spec.md at the v0.22.1 SHA.
  2. Update docs/SPEC-PIN.md (and any pyproject.toml-pinned reference) to the new SHA + version label.
  3. Audit contract texts that reference the old pin — update version string + SHA in all assumptions: blocks.
  4. Decide whether to opt into memory_context (Phase 2.1) — separate follow-up.

Out of scope

  • Pre-implementing the subject:{type,id} migration (Worldtree #196) — separate ratatoskr issue.
  • Adopting memory_context — separate follow-up if we want it.

Why now

The pin lies about what surface we're committed to. Worldtree-dev flagged the delta on 2026-05-23.

## Context Our vendored Worldtree Conversation API spec pin is at v0.19.0 (commit `55101e909abcd2219833266b6f905c5bc956e0f0`). Worldtree shipped v0.20.0, v0.21.0, and v0.22.x since (current is v0.22.1) per worldtree-dev's 2026-05-23 reply (althing thread `01KSBARG2B8M8C82H6AJGJWX1B`). ## What changed between v0.19.0 and v0.22.1 (consumer-relevant) - **v0.20.0** (#185): `end_user_id` became the partition key for long-term memory + persona/valence state. - **v0.21.0** (#189): Phase 2.1 added optional `memory_context: list[dict]` field to `POST /sessions/{id}/messages`; appended to per-turn system prompt as `[MEMORY:DATA ...]` blocks. - **v0.22.0** (#197): ContextPromotion + STM tier removal; the `[MEMORY:DATA]` envelope was strengthened. - **v0.22.1**: current head (point-fix on top of v0.22.0). None of these break ratatoskr's existing surface — `POST /sessions`, `POST /sessions/{id}/messages` SSE, and `POST /sessions/.../turns/{tid}/cancel` are stable. ## What's needed 1. Re-vendor `docs/conversation-api-spec.md` from `~/development/Worldtree/docs/conversation-api-spec.md` at the v0.22.1 SHA. 2. Update `docs/SPEC-PIN.md` (and any `pyproject.toml`-pinned reference) to the new SHA + version label. 3. Audit contract texts that reference the old pin — update version string + SHA in all `assumptions:` blocks. 4. Decide whether to opt into `memory_context` (Phase 2.1) — separate follow-up. ## Out of scope - Pre-implementing the `subject:{type,id}` migration (Worldtree #196) — separate ratatoskr issue. - Adopting `memory_context` — separate follow-up if we want it. ## Why now The pin lies about what surface we're committed to. Worldtree-dev flagged the delta on 2026-05-23.
vh added the needs-triagedocumentationtask labels 2026-05-23 14:24:45 -07:00
vh commented 2026-05-29 23:27:17 -07:00
Author
Owner
Copy Link
Copy Source

Closed — superseded. Target was v0.19.0 → v0.22.1; the spec pin has since advanced to v0.29.0 (commit 562001a, pinned 2026-05-26) via the v0.11.0/v0.13.0/v0.14.0 integration arcs. The v0.22.1 intermediate refresh is moot — we're seven minors past it and all consumer surfaces (POST /sessions, messages SSE, cancel) remain stable. memory_context (Phase 2.1) opt-in remains a separate untracked follow-up if ever wanted.

Closed — superseded. Target was v0.19.0 → v0.22.1; the spec pin has since advanced to v0.29.0 (commit 562001a, pinned 2026-05-26) via the v0.11.0/v0.13.0/v0.14.0 integration arcs. The v0.22.1 intermediate refresh is moot — we're seven minors past it and all consumer surfaces (POST /sessions, messages SSE, cancel) remain stable. memory_context (Phase 2.1) opt-in remains a separate untracked follow-up if ever wanted.
vh closed this issue 2026-05-29 23:27:33 -07:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked-needs-contract
Sleipnir refuses dispatch — issue-scoped contract missing
 blocked-needs-dependency
Sleipnir holds dispatch — INV-029 dependency-aware gate
 bug
Something is not working
 cli
Command-line surface (--send, --new, --session, etc.)
 documentation
Docs / contract / spec work
 duplicate
Duplicate of another issue
 enhancement
New feature or improvement
 invalid
Not a real issue
 needs-architect-decision
Escalated for a design call
 needs-info
More info required from reporter
 needs-triage
Newly filed, not yet sorted
 observability
Log-pane / debug-surface work (persona, admin events, Bifrost, tools)
 ready-for-agent
Gates AFK dispatch via Sleipnir (applied by /sleipnir-preflight)
 sse-client
SSE consumer module (src/ratatoskr/sse_client.py)
 task
Implementation task
 tui
Textual app shell + presenters
 wontfix
Accepted as not-fixing
No Label documentation needs-triage task
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
vh
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vh/ratatoskr#9
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?