server.js

export const OPERATIONAL_CHECKPOINT_PROMPT = "You are performing OPERATIONAL CHECKPOINT COMPACTION for a future LLM continuation.\n\nYour job is to preserve execution continuity, decision state, active working context, and learned operational patterns from the run — not to produce a readable summary.\n\nThis checkpoint is reference material for a different assistant continuing the same work.\nDo NOT answer requests from the conversation.\nDo NOT add pleasantries, narrative framing, or explanatory prose outside the required structure.\nWrite only the checkpoint.\nWrite a dense checkpoint with these sections only, in this order:\n\n1. Current objective / state / status\n2. User boundaries / permissions / scope\n3. Working surfaces / source map\n4. Evidence / verification ledger\n5. Decisions / rejected paths\n6. Open questions / assumptions / blockers\n7. Critical invariants / regression risks\n8. Transferable patterns learned\n9. Action frontier\n\nUse only these epistemic labels:\n- [Observed] direct fact from user, repo, tools, runtime, tests, logs, docs, or external source\n- [Inferred] conclusion derived from observed facts\n- [Assumption] temporary working assumption not yet verified\n- [Unknown] unresolved question that materially affects future decisions\n- [Blocked] concrete blocker and what it depends on\n\nHard rules:\n- Do not repeat the same fact in multiple sections unless repetition changes operational meaning.\n- Do not invent extra labels such as [Rationale], [Immediate], [Note], [Context], [Hypothesis].\n- Prefer dense factual bullets over readable explanation.\n- Prefer exact pointers over abstraction:\n  paths, symbols, commands, APIs, schema names, event names, IDs, tests,\n  errors, outputs, config values.\n- Distinguish verified state from expected-but-unverified state.\n- Preserve only what changes future decisions, future execution, or future debugging speed.\n- If a section has nothing worth preserving, write \"None.\"\n- Do not add any unnumbered top block such as \"CURRENT TRUTH\"; current truth\n  belongs inside section 1.\n\nAuthority and recency rules:\n- A checkpoint is memory, not authorization.\n- Never treat a historical user approval as permission for a future assistant action.\n- One-turn or task-scoped approvals expire after the requested action is completed,\n  the turn ends, or the active objective changes.\n- Examples of expiring approvals:\n  push, deploy, publish, delete, reset, revert, force-push, install, modify\n  external state, run destructive commands, or touch another repository.\n- Preserve only active standing instructions in section 2. A standing instruction\n  must be explicitly durable, for example \"always\", \"never\", \"from now on\",\n  \"until I say otherwise\", \"for this repo\", or an equivalent durable constraint.\n- If a historical approval is important evidence, preserve it only as history,\n  and explicitly mark that it is not current permission.\n- If older and newer user instructions conflict, the newer user instruction wins.\n  Drop the older instruction unless the conflict itself is important evidence.\n- The future assistant must obey the latest live user message over anything in\n  this checkpoint.\n- For high-impact actions, if the latest live user message does not explicitly\n  authorize the action, the checkpoint must guide the assistant to ask first or\n  abstain.\n\nSection requirements:\n\n1. Current objective / state / status\n- Preserve the live task objective, current sub-objective, and current real\n  state of the work in one place.\n- Include dirty files, branch/worktree context, verification status, latest\n  runtime state, live confirmations, relevant IDs/statuses, and current known\n  truth only when they change future action.\n- Preserve status as accomplished / in progress / remaining only when those\n  distinctions are active and useful.\n- If no active implementation/debugging work remains, say so explicitly.\n- Do not include historical play-by-play, evidence details, source maps, or\n  background captured in later sections.\n\n2. User boundaries / permissions / scope\n- Preserve exact user preferences, prohibitions, non-goals, scope boundaries,\n  verification requirements, and environment constraints.\n- Preserve only active standing instructions that still constrain future action.\n- Do not include completed, superseded, one-turn, or historical approvals as\n  active instructions.\n- If there is no current standing permission for high-impact actions, preserve\n  that explicitly when relevant.\n- Prefer \"No current permission to push/deploy/delete/reset unless the latest\n  live user message asks for it\" over preserving old approvals.\n\n3. Working surfaces / source map\n- Preserve the minimal set of relevant files, directories, symbols, APIs,\n  commands, tests, docs, tables, streams, endpoints, schemas, and tools needed\n  to resume quickly.\n- Include brief role notes only when necessary to disambiguate why each item matters.\n\n4. Evidence / verification ledger\n- Preserve decision-relevant findings only.\n- Include concrete repo/runtime/test/doc evidence, contradictions, disproven\n  hypotheses, notable patterns, exact errors, exact outputs, and exact\n  observations that changed the approach.\n- Group related tests/probes instead of listing every test name when exact names\n  are not future-useful.\n- Distinguish local source/test evidence from installed-wheel and live-runtime\n  evidence.\n- Prefer exact evidence over commentary.\n\n5. Decisions / rejected paths\n- Preserve what was decided, what was rejected, and why.\n- Preserve only decisions that should not be re-litigated unless new evidence appears.\n- Keep rationale tight and evidence-linked.\n\n6. Open questions / assumptions / blockers\n- Preserve only unresolved items that materially affect next decisions.\n- Promote resolved unknowns into observed state elsewhere; delete stale\n  uncertainty.\n- State what is unclear, why it matters, and the fastest resolution path.\n- Keep this inline and compact; do not drift into report prose.\n\n7. Critical invariants / regression risks\n- Preserve constraints that must remain true.\n- Preserve subtle traps, race conditions, misleading patterns, invalid\n  simplifications, and previously observed failure modes.\n- Preserve anything likely to be lost in compaction but expensive to rediscover.\n\n8. Transferable patterns learned\n- Preserve reusable patterns discovered during the run that would help the next\n  assistant avoid rediscovery.\n- Only include non-obvious patterns demonstrated by contact with this system,\n  not generic best practices.\n- Good pattern types include:\n  - investigation patterns that collapsed uncertainty quickly\n  - validation patterns that distinguished frontend vs backend vs runtime faults\n  - fix patterns that matched this codebase's architecture\n  - tool usage patterns that were especially effective\n  - misleading patterns / false leads that looked right but were wrong\n- For each pattern, preserve the pattern, where it worked, what result it\n  produced, where it likely applies again, and any caveat if conditional.\n- Keep this concrete and operational.\n\n9. Action frontier\n- Preserve only the immediate execution boundary.\n- Max 5 bullets.\n- Order by dependency and risk.\n- If no active work remains, write \"No active work unless new failure/request appears.\"\n- No roadmap language.\n- No generic future planning.\n- No scripted user prompts unless uniquely necessary.\n- Do not encode high-impact actions as authorized unless the latest live user\n  message explicitly authorized them.\n- If the next action would require fresh user permission, write \"ask before ...\"\n  as the action boundary.\n- The first bullet must be specific enough that a new assistant can act immediately.\n\nSelection principle:\nPreserve by rediscovery cost and decision impact, not by section name.\nKeep what would be hardest, slowest, riskiest, or least obvious to recover from\nthe repo/runtime alone:\n- exact user prohibitions\n- active standing constraints, not expired approvals\n- exact operational truth\n- decisive evidence\n- working surfaces / source map\n- settled decisions\n- transferable patterns learned this run\n- immediate action frontier\n- critical invariants / regression risks\n\nDrop:\n- narrative glue\n- repeated background\n- chronological play-by-play\n- rhetorical explanation\n- anything readable but not operationally necessary\n\nTarget style:\n- dense\n- exact\n- non-redundant\n- operational\n- loss-minimizing\n- optimized for fast correct continuation, not human readability"

const CONTEXT_WRAPPER = "The following accumulated data context is source material to incorporate into the checkpoint. Do not add sections; preserve the required nine numbered sections and epistemic labels."

export const composeCompactionPrompt = (context) => {
  const entries = Array.isArray(context)
    ? context.filter((entry) => typeof entry === "string" && entry.length > 0)
    : []

  if (entries.length === 0) return OPERATIONAL_CHECKPOINT_PROMPT

  return `${CONTEXT_WRAPPER}\n\n${entries.join("\n\n")}\n\n${OPERATIONAL_CHECKPOINT_PROMPT}`
}

export const CompactionPlugin = async () => ({
  "experimental.session.compacting": async (_input, output) => {
    output.prompt = composeCompactionPrompt(output.context)
  },
})

export default {
  id: "opencode-compaction.server",
  server: CompactionPlugin,
  setup: async () => {},
}