tommy0103/obelisk

Proposal Add a minimax provider adapter that indexes MiniMax Code (mcode) session history alongside the existing claude / codex / deepseek / kimi / pi providers. Full design spec: docs/minimax-provider-adapter-spec.md (currently in the working tree; will accompany the implementation PR). Source format mcode has two runtime generations on disk; v1 (event-sourced ledger.jsonl) is retired, v2 is current: Data root ~/.minimax (legacy ~/.mavis); sessions under v2/sessions/YYYY/MM/DD/<sessionDir>/ — grouped by creation date, not by project. messages.jsonl: the canonical LLM history, one envelope per line (message_id, turn_id, Pi-format message body, optional turn_config, optional history_artifact at position 0). Session metadata (title, workspaceDir, parent links) lives only in v2/sqlite/runtime-state.sqlite. Compaction rewrites messages.jsonl wholesale: the pre-compaction history is first published to an immutable snapshots/gNNNN--<compactionId>.jsonl, then the file restarts from a compa

Evaluation: Obelisk on real coding tasks This report evaluates whether access to prior coding-agent history improves real software-engineering work. It covers three complementary settings: Cross-task archive: 81 SWE-bench tasks over four repositories, with history produced by other agents on earlier issues. Own-failure retry: 34 frozen SWE-bench failures, with the agent's failed attempt available as history for a second attempt. Longitudinal work: one fixed sequence of six real jazzband/tablib issues, where the same agent configuration accumulates its own prior sessions across tasks. The first two panels use official SWE-bench test grading. The longitudinal panel uses the CL-Bench codebase_adaptation grader. All effective runs use deepseek-v4-flash through Pi. Executive result Other agents' cross-task history: the official Obelisk skill produced exactly the same result as no memory on the content-clean primary panel: 34/68 vs 34/68, paired difference 0.0 pp (95% bootstrap CI -5.9 to

TL;DR Replaying a Kimi context.undo event leaves injection messages in the index that Kimi itself removed from the context. Low impact today — the leftovers are reminder-class records — but the divergence should be closed before undone content is ever surfaced rather than dropped. Priority: low. No user-visible symptom has been observed. This is a fidelity gap found by reading both implementations side by side, not a reported bug. Problem Kimi's context.undo is a tail truncation at a user-turn boundary: it removes the last N real user prompts and everything that followed them. The Kimi adapter replays that event to keep the index consistent with what Kimi actually has in context. The two implementations disagree on one class of record. Kimi counts injection messages as non-undoable when deciding where to cut, but still removes them when applying the cut. The adapter treats "skip while counting" as "skip while removing", so injections inside the undone range survive into the index