Orchestrata Ultimate › Plans › spec-021-port-map

SPEC-021 Port Map — OpenCode Integration → orchestrata-ultimate

Source: plans/spec-021-port-map.md at 8a2cb42ad · last changed 2026-07-27 · first committed 2026-07-13 · 518 lines.

Prose pending.

Plan text

SPEC-021 Port Map — OpenCode Integration → orchestrata-ultimate

Read-only audit. Source: /home/mohamed/workspace/orchestrata/open-code/ (frozen). Deployed twin: ~/.opencode/ (running @opencode-ai/plugin@1.3.15, confirmed via ~/.opencode/node_modules/@opencode-ai/plugin/package.json). Oracle: specs/021-opencode-integration/spec.md + checklists/requirements.md (295 REQ-021 rows, not 299 — see drift note) + checklists/testing.md.

Classifications: PORT-CLEAN (works as-is) · RETARGET (needs concrete path/id/schema changes, named below) · BUILD-NEW (no backend exists in ultimate) · OBSOLETE/SUPERSEDED (ultimate already does this, differently or better).

0. CRITICAL — read this before planning any wave

Most of the plugin's advertised lifecycle behavior almost certainly never fires in the deployed app, independent of any porting work. orchestrata.ts registers 8 top-level hook keys on the object it returns:

session.status, session.created, session.idle, tool.execute.before,
tool.execute.after, message.updated, file.edited, experimental.session.compacting

The actual Hooks interface exported by @opencode-ai/plugin — checked in both the version pinned by the source config/package.json (1.3.3, reference copy at open-code/reference/node_modules/@opencode-ai/plugin/dist/index.d.ts:123-247) and the version physically installed at the live deployment target, ~/.opencode/node_modules/@opencode-ai/plugin (resolved to 1.3.15 per its package.json, type surface at ~/.opencode/node_modules/@opencode-ai/plugin/dist/index.d.ts:142-267) — contains only:

event, config, tool, auth, provider, chat.message, chat.params, chat.headers,
permission.ask, command.execute.before, tool.execute.before, shell.env,
tool.execute.after, experimental.chat.messages.transform,
experimental.chat.system.transform, experimental.session.compacting,
experimental.text.complete, tool.definition

Of the plugin's 8 registered keys, only 3 are real: tool.execute.before, tool.execute.after, experimental.session.compacting. The other 5 — session.status, session.created, session.idle, message.updated, file.edited — are not part of the Hooks type in either version. Session-lifecycle and file-edit notifications do exist in the SDK, but only as members of the discriminated Event union consumed through the single generic event hook (@opencode-ai/sdk types.gen.d.ts:602: EventSessionStatus | EventSessionIdle | ... | EventFileEdited | EventSessionCreated | ..., with EventSessionIdle at line 413 type: "session.idle", etc.) — i.e. the correct pattern is event: async ({ event }) => { switch (event.type) { case "session.idle": ... } }, not a dedicated "session.idle" key on the returned object.

Because OrchestrataPlugin (open-code/plugins/orchestrata.ts:19) has no return-type annotation (Plugin is never applied to it), TypeScript performs no excess-property check and the file compiles cleanly despite exporting 5 dead keys. Whether the actual Go/Bun OpenCode host loosely dispatches by matching hooks[event.type] for any string (in which case these might work despite being unlisted) cannot be confirmed from static .d.ts files alone — this must be verified by runtime instrumentation (e.g. temporarily add console.error at the top of each of the 5 handlers and observe a live OpenCode session) before treating any of the following as "working code to port":

• Session auto-start/resume + banner (US-002, FR-002)
• Session auto-end + git-log achievements + archive (US-002, FR-003)
• KG sync queue flush + conversation queue flush tied to session lifecycle (US-007, US-009)
• Deception detection audit (US-004, FR-007) — triggers on session.idle
• "remember when" memory search + "close the session" detection (US-008, FR-012) — triggers on message.updated
• The entire 5-gate code review pipeline (US-003, FR-005/FR-006) — triggers on file.edited

Only these are on solid ground: KG context injection + policy enforcement + git checkpoint (tool.execute.before), tool-call/operation logging (tool.execute.after), the compaction context injector (experimental.session.compacting), and all 28 custom tool entries (the tool field IS in the real Hooks interface, and each tool definition structurally matches ToolDefinition — tool.d.ts — even though none of them call the exported tool() helper; TS structural typing accepts the plain object literals). Recommendation: any rebuild should re-home the 5 dead-hook behaviors onto a single event handler with a switch(event.type), not copy the current key names verbatim.

1. Spec-vs-artifact drift (spec claims that don't survive contact with the code)

2. Concrete bugs found in the source artifact (carry-forward risk if ported verbatim)

These are defects in the source TypeScript/Python, independent of porting — flagged so none of them get silently reproduced.

1. kg-daemon-start/stop/status process-matching is broken. The daemon is launched via nohup python3 -c '...' (orchestrata.ts:2224) whose argv never contains the literal string "kg-sync-daemon", yet kg-daemon-start checks pgrep -f "kg-sync-daemon" (2215), kg-daemon-stop runs pkill -f "kg-sync-daemon" (2321), and kg-daemon-status re-checks the same pattern (2348). None of the three can ever find the process they started — start never detects "already running" (duplicate daemons possible), stop never kills it, status always reports NOT running even while it is.
2. conv-sync's embedded Cypher is not valid Cypher. orchestrata.ts:2898-2906 contains WITH c \n OPTIONAL MATCH (os:OrchestrataSession {seq: $seq}) \n IF os IS NOT NULL \n MERGE (c)-[:FOR_SESSION]->(os) — bare IF is not Cypher grammar (no CASE/APOC). Every invocation of conv-sync with pendingCount > 0 throws a Neo4j syntax error, caught only generically as Sync failed: .... The equivalent flush inside session.created (orchestrata.ts:519-523) omits this broken clause and is fine.
3. code-fix's mutable-default-arg regex has unbalanced parentheses, orchestrata.ts:3207: r'def \w+\s*\(([^)]*=)\s*\[)(,|\))' — contains a stray unmatched ) (and a literal \[ that looks like a typo for \)). re.sub with this pattern raises re.error in Python at runtime; the whole code-fix tool invocation fails every time (uncaught inside the python3 -c heredoc, surfaces as a generic Fix failed: ... in TS).
4. Gate 3's bare-except:-with-pass check references an undefined variable. orchestrata.ts:1380: for i, line in enumerate(lines): — lines is defined only in the separate Gate 4 try-block (1461), not in the Gate 3 block (1352-1454) where this loop lives. Any file containing a bare except: triggers a NameError, which the wrapping except Exception as e at 1453 silently swallows into a generic CONTENT CHECK warning — meaning the bare-except detector (and everything textually after it in that same try-block: logging checks, mutable-default check, @traces traceability check) silently stops running for any file that has the very pattern it's supposed to flag.
5. session_cli.py end --achievements "..." / --upcoming "..." loses all but the last value. session_cli.py's end subcommand defines --achievements with nargs="*" (~/.claude/tools/session_cli.py:503) — i.e. it expects --achievements "A" "B" "C". But the plugin builds achievements.join('" --achievements "') (orchestrata.ts:629,1115,1857), producing --achievements "A" --achievements "B" --achievements "C" — repeated occurrences of the same flag in argparse overwrite, they don't accumulate, so args.achievements ends up ["C"] only. Every session close with 2+ achievements silently drops all but the last one. Same shape of bug applies to --upcoming.
6. Project-scope leakage via substring match. Every KG/Redis-gated tool checks directory.includes("orchestrata") (e.g. orchestrata.ts:1986, 2033, 2055...). This substring also matches /home/mohamed/workspace/orchestrata (frozen source), orchestrata-ultimate (an earlier scaffold), orchestrata-ultimate-architecture (this repo), and orchestrata-backup-* — meaning any of these sibling checkouts opened in OpenCode would fire the same production Neo4j/Redis writes. Not new in the port, but should be tightened (e.g. exact directory match or a project-id file check) rather than carried forward.
7. packages/ path filter never matches ultimate's tree. file.edited's gate (orchestrata.ts:1217: filePath?.includes("packages/") && filePath?.endsWith(".py")) and the module-import derivation (1332-1337: splits on /packages/, builds orchestrata.{pkg}.{module}) both hard-assume the 26-package monorepo layout. Ultimate's source lives at src/orchestrata_ultimate/... with no packages/ segment and a single top-level import package (orchestrata_ultimate.*, not orchestrata.<pkg>.<module>) — see CLAUDE.md Quick Reference. Even if the hook fired (§0), the filter would never trigger and the import-check logic would build a nonexistent module path.

3. Functional-unit inventory & classification

3.1 Lifecycle hooks (orchestrata.ts top-level keys)

3.2 Helper functions (pure logic, no I/O — trivially portable)

3.3 Custom tools (28 total — see D2)

3.4 Agents, commands, config

3.5 Python KG query tools (tools/)

3.6 Redis queue infra

4. What I did NOT get to / could not fully verify

• The exact relationship name linking Violation/Escalation nodes to Session nodes (needed to correctly retarget kg-session-audit's Cypher) — confirmed only that Session, Violation, and Escalation labels are each independently real (§6, §3.3), and that gateway/audit.py:39 merges (s:Session {session_id: $connection_id}); did not trace the audit/violation-writer code far enough to name the actual edge type. A builder should grep governance/audit.py, governance/violations.py, and gateway/audit.py for how they connect an event node to its owning session before writing this tool's Cypher.
• Whether CXPPacket or canonical Message is the label actually queried against in the live running graph (§3.3/§6.1) — both exist in code (writer vs. canonical-schema-intent) but which one has real data was not checked against a live Neo4j instance.
• code-review.py's three coverage gaps (generic secret detection, feature-envy, nesting depth — §6.8) mean a builder wiring the file.edited gate onto code-review.py alone will under-deliver relative to the old plugin's Gate 3/4 unless checks_structure.py and/or claude/hooks/error_gate/checks_structure.py are also wired in, or new checks added.
• I did not execute or instrument a live OpenCode session to empirically confirm or refute §0's hook-dispatch hypothesis — this is a static-analysis conclusion from two installed .d.ts files, not a runtime trace. Treat §0 as "very likely, high-confidence, but not empirically observed."
• I did not review open-code/reference/node_modules/ in full (only the plugin/sdk type stubs relevant to hook dispatch) — the bun.lock/package.json dependency graph beyond @opencode-ai/plugin and zod was not audited.
• compliance-audit.md (613 KB / 12,560 lines) was only skimmed for its ~50-line summary, per the size-safety rule; I did not read the rest, but the summary already establishes it's auditing the wrong spec (TodoistIntegration) so the remaining 12,500 lines are unlikely to contain anything SPEC-021-relevant.
• REQ-021 cross-references above are traced at the group level (e.g. "REQ-021-054..070"), not restated per-row; a full row-by-row REQ-021 ↔ code-line mapping table (295 rows) was not produced given the size of this task — the groupings in §3 should be sufficient to assign wave ownership without enumerating every row.

5. Verified PORT-CLEAN surface (cross-checked directly against ultimate)

• session_cli.py — same absolute path (~/.claude/tools/session_cli.py) already used project-wide; not project-specific, needs no retargeting. Subcommands the plugin calls — status --json, begin --purpose, end --achievements/--upcoming, log-work --desc --details, log-artifact --path --lines --summary, log-choice --choice --reason, log-achievement --item, add-work --text --priority --notes, complete-work --text, update-state --version --branch --test-state --status, --json — all exist with matching flag names (session_cli.py:475-593), except the nargs="*" accumulation semantics bug (#5 above) which affects --achievements/--upcoming specifically.
• context.json schema — top-level keys state, deferred_work, session_history (confirmed via direct read of this repo's own context.json); session_history[] entries carry seq, when, purpose, achievements, log, upcoming — exactly the fields the "remember when" Python one-liner (orchestrata.ts:961-996) expects. state carries version, git_branch, status_line, test_state — matching the session banner's state?.version/.git_branch/.test_state reads and cmd_status's state.model_dump() (session_cli.py:117-126).
• .claude/hooks/ already independently implements the security-relevant half of US-005 (no-mock, no-banned-deps, no-xdist) as Claude Code PreToolUse/Stop hooks — this is why §3.2 marks those three policy functions OBSOLETE/SUPERSEDED rather than RETARGET.

6. Ultimate-side equivalents (KG schema, sync, review pipeline)

Confirmed by a dedicated research pass over the current src/orchestrata_ultimate/ tree (all citations below are that pass's, cross-checked, plus a few items I confirmed independently as noted).

6.1 Canonical KG labels / relationships

Labels are plain, undecorated names — not CodeClass/CodeFunction/CodeFile as kg-trace-req assumes (canonical_schema.py): Module (74), Class (75), Function (76 — methods are also Function nodes, carrying a class_id property, no separate Method label), Spec (77), Requirement (78), RequirementItem (79), Project (82), Package (94), File (95), Directory (96).

Canonical relationships settled by canonical_schema.py (lines 151-153) are only three: REL_DEFINES = "DEFINES" (the one containment edge, replacing writer-specific HAS_CLASS/HAS_FUNCTION/HAS_METHOD), REL_TESTED_BY = "TESTED_BY", REL_TRACES_TO = "TRACES_TO" (always targets RequirementItem, never Requirement directly — comment at lines 149-150). The module's own docstring (46-49) states these are the only canonical names; HAS_FILE/CONTAINS/DEFINES_REQUIREMENT/HAS_ITEM/HAS_METHOD still live in the older, uncoordinated knowledge_graph/schema.py (lines 63-83), which per that module's own comment remains "the live writer surface until a later wave migrates." There is no HAS_REQUIREMENT relationship in canonical_schema.py at all — it exists only as a literal string in semantic_graph/spec_trace_enricher.py:207, an unrelated writer. This means kg_query_inner.py's project-scoping rewrite (which anchors through HAS_FILE/HAS_SPEC/ HAS_REQUIREMENT) is targeting relationship names that are, at best, legacy/non-canonical and at worst don't exist under those exact names for Requirement.

6.2 Node-ID convention — project-qualified ids ARE real, but two co-existing schemes

Confirmed: canonical_schema.py's docstring (15-26) documents the move from bare <relpath>::<qualname> to project-qualified <project>:<relpath>::<qualname> (dated 2026-07-12 — i.e. very recent). However the module's own code_entity_id() helper (canonical_schema.py:371-396, still called from knowledge_graph/ontology_mapping.py:132) has not been updated and still returns the bare f"{relpath}::{qualname}" — while the actual writer (knowledge_graph/sync.py) builds ids inline, already project-qualified, bypassing that helper:

• Class/Function id: f"{project}:{qname}" where qname is qualified_name or f"{mod_path}.{name}" (sync.py:318-333, 363-375)
• Module id: f"{project}:module:{path}" (sync.py:292-301)
• Project node: MERGE (p:Project {id: $id}) SET p.slug = $slug, ... with id = name = slug = project (sync.py:198-220); canonical merge key per canonical_schema.py:183/300 is slug, constraint project_slug
• File id: f"{project_id}:{path}" (knowledge_graph/kg_context.py:596-606, matches canonical_schema.py:196's documented writer key)

Net effect for the port: any retargeted Cypher should build ids as f"{project}:{qualified_name_or_path}" directly (matching the live sync.py writer), not call the stale code_entity_id() helper, and not assume a global Project reachability traversal the way kg_query_inner.py does — a direct {project}: prefix match/filter is now the correct (and cheaper) scoping mechanism.

6.3 FileSynchronizer — EXISTS, 1:1 rename target

src/orchestrata_ultimate/knowledge_graph/synchronizer.py:38, class FileSynchronizer (@traces(spec="008", story="US-001", reqs=["REQ-008-022","REQ-008-025"])), with sync_file(self, file_path: str) -> SyncResult (line 71-72, same name/purpose as the old plugin's usage) plus sync_project(...) (384) and sync_project_with_resolution(...) (434). Import path changes only the package prefix: orchestrata.knowledge.synchronizer → orchestrata_ultimate.knowledge_graph.synchronizer; class and method names are unchanged. This retargets the KG-sync-queue consumer tools (kg-sync, kg-flush-queue, kg-daemon-*) from BUILD-NEW to a much smaller RETARGET: the consumer logic itself (SPOP loop, error handling) is unchanged, only the import line and module path.

6.4 No standalone "sync one file" script exists — use FileSynchronizer directly, not a CLI

Checked all three candidate full-repo scripts; none accepts a single source-file path:

• scripts/ingest_orchestrata_ultimate.py — full-repo (or --prune-stale-labels) only, no file arg at all (main() at line 239 walks SOURCE_DIR unconditionally); targets the Memgraph semantic graph, not Neo4j — wrong target entirely for this port.
• scripts/sync_ast_to_neo4j.py incremental --ast --project --modules (subcommand at lines 253-262) takes a comma-separated module-path list against a pre-built AST JSON, not a raw file path — not a drop-in single-file sync.
• scripts/bootstrap_graphs.py — whole-graph bootstrap/check/plan only, no file/target arg (_build_parser() line 305).

Conclusion: the old plugin's python3 scripts/sync_monorepo_to_neo4j.py (full-repo, background) and the ad-hoc from orchestrata.knowledge.synchronizer import FileSynchronizer; syncer.sync_file(f) (single-file, queue-driven) map onto two different existing ultimate tools: full/background sync → scripts/ingest_orchestrata_ultimate.py (if repointed at the Memgraph graph is acceptable) or scripts/bootstrap_graphs.py --neo4j; single-file incremental sync → call FileSynchronizer.sync_file() directly from Python (as the old plugin already does), no new CLI needed.

6.5 Neo4jClient/Neo4jConfig — EXISTS, stable import path, matching async surface

knowledge_graph/neo4j_client.py:42 — class Neo4jClient(Neo4jNodeCreationMixin, Neo4jFileQueryMixin) with async def connect(self) -> bool (64), async def close(self) -> None (94), async def query(self, cypher, parameters=None) -> list[dict] (273). knowledge_graph/config.py:27 — @dataclass class Neo4jConfig with uri, username, password, database, max_pool_size, max_connection_lifetime, connection_timeout fields. Import paths: orchestrata_ultimate.knowledge_graph.neo4j_client.Neo4jClient / orchestrata_ultimate.knowledge_graph.config.Neo4jConfig — same package-prefix rename as §6.3, method surface (connect()->bool, query(cypher,params)->list[dict], close()) matches the old plugin's expectations closely. (A separate sync Neo4jSyncRepository also exists for non-async call sites, e.g. session/kg_context.py, core/graph.)

6.6 KnowledgeGraphContext.get_file_context — ALREADY PORTED

This is not a retarget — it's done. src/orchestrata_ultimate/session/kg_context.py:23 carries @traces(spec="021", story="US-001", reqs=["REQ-021-004"]) on the class itself and again on the method (line 84) — confirmed by direct grep (grep -rn 'spec="021"' src/ → exactly these 2 lines, nothing else in the whole tree). Import path is identical save the package prefix to the old plugin's usage: orchestrata.session.kg_context.KnowledgeGraphContext → orchestrata_ultimate.session.kg_context.KnowledgeGraphContext. Signature: get_file_context(self, file_path: str) -> dict, returning {"file": ..., "lines": ..., "entities": [{"type", "name", "has_docstring"}, ...], "specs": [spec_id, ...]} (lines 85-106) — a reasonable superset of what the old plugin printed. The class also exposes connect()/close()/connected, get_spec_context(spec_id) (108), and get_class_context(class_name) (151) — more than the old plugin used. This reclassifies tool.execute.before's KG-context-injection call and the kg-file-context tool from RETARGET to near-PORT-CLEAN: swap the import path, done. (A different, broader knowledge_graph/context_injector.py:404 ContextInjector class also exists but has no get_file_context method — don't confuse the two.)

6.7 Redis KG-sync-queue / conversation-queue consumers — confirmed BUILD-NEW

No consumer or producer exists for either Redis key pattern anywhere in src/ or scripts/. A constant REDIS_KG_SYNC_PREFIX = "orchestrata:kg:sync" (knowledge_graph/constants.py:25) exists but is dead — referenced only by its own definition and a unit test asserting its literal value (tests/knowledge_graph/test_constants.py:38); nothing produces to or consumes from it. HistoryManager (knowledge_graph/history.py:31) optionally accepts a redis.Redis client but is an in-memory change-history log, unrelated. Conversation/ConversationTurn/ HAS_TURN do not exist anywhere in src/orchestrata_ultimate/ (zero grep hits) — they appear only in the old plugin file itself and in planning docs. This confirms §3.3/§3.6's BUILD-NEW classification for the whole conversation-tracking subsystem, with no shortcut available.

6.8 scripts/code-review.py — real gate-by-gate coverage (supersedes most of Gates 1-5)

CLI: paths (nargs="+", files or directories) + --output/-o, --format {text,json,markdown}, --min-severity {ERROR,WARNING,INFO}, --fix, --format-code, --max-files, --diagnostics, --stdout (code-review.py:1888-1932). Checkers wired in main() (1950-1962): RuffFormatChecker, RuffChecker, MyPyChecker, StyleChecker, ChecklistChecker, ConnectionStringChecker, TraceabilityChecker, plus a standalone check_banned_dependencies (1845). Confirmed check-by-check against the old plugin's Gate 3/4/5 items:

Conclusion: scripts/code-review.py is a strong but incomplete drop-in replacement for the embedded 5-gate heredoc — it covers syntax/format/lint/mypy, bare-except, mutable defaults, @traces presence, and naming outright, but is missing a generic secret-detector, a feature-envy check, and (in this script specifically) nesting-depth — those three would need to be added to code-review.py (or pulled from checks_structure.py / claude/hooks/error_gate/) if full Gate 3/4 parity with the old plugin is actually wanted, rather than assumed available.

7. Counts

(Counts are unit-groupings, not the raw 295-REQ tally — see §4 for why a full row-level count wasn't produced.)

8. Suggested W1/W2 work packages, in dependency order

W1 — foundation (must land before anything else is meaningful)

1. Verify §0 empirically. Instrument a live OpenCode session (temporary console.error at the top of session.created/session.idle/message.updated/file.edited) and confirm whether they fire at all. This single result determines whether W1.2-W1.4 below are a rewrite-onto-event job or a "these never ran, design fresh" job.
2. Only one KG-schema question remains open per §4/§6: the exact relationship name linking Violation/Escalation to Session (needed for kg-session-audit). Everything else (canonical labels/ids, FileSynchronizer, KnowledgeGraphContext.get_file_context, which full-sync script to use) is now confirmed — see §6.
3. Decide canonical config: reconcile source open-code/config/opencode.json (2-line stub) vs. the deployed, hand-extended ~/.opencode/opencode.json (model/permission/plugin block) before any redeploy can safely overwrite it.
4. Bump @opencode-ai/plugin pin to the version actually verified in W1.1, regenerate bun.lock.

W2 — rebuild the hook surface onto event (depends on W1.1)

1. Re-home session.created, session.idle, message.updated, file.edited, session.status logic into a single event: async ({event}) => switch(event.type){...} handler.
2. Fix bug #5 (session_cli.py end --achievements) while doing so — pass a real space-separated multi-arg invocation, not the quote-splicing hack.
3. Retarget file.edited's path filter from packages/*.py to src/orchestrata_ultimate/**/*.py (and tests/**/*.py if desired) and replace the entire embedded 5-gate heredoc with a call to scripts/code-review.py <file> --format json --min-severity ERROR (fixes bugs #3, #4 for free by deleting the code that had them). Per §6.8, code-review.py alone does not fully replace Gates 3/4: no generic secret detector, no feature-envy check, no nesting-depth check. Decide explicitly whether to (a) accept the gap, (b) also wire in verification/review/checks_structure.py for god-object/nesting, or (c) add the missing checks to code-review.py directly — don't assume "replace with code-review.py" is 100% parity by default.
4. Retarget the KG-context-injection subprocess call in tool.execute.before to orchestrata_ultimate.session.kg_context.KnowledgeGraphContext (§6.6) — this one is nearly free, the class already exists with a matching signature and is already traced to REQ-021-004.

W3 — retarget the 28 tools (depends on W1.2)

1. Session tools (9): near-zero work — already PORT-CLEAN, just fix bug #5 in session-end.
2. KG query tools (kg-query, kg-find-file, kg-find-entity, kg-stats, kg-cxp-thread, kg-trace-req, kg-file-context): rewrite Cypher/labels per confirmed §6 schema.
3. kg-sync/queue-status/flush-queue/daemon×3: rewrite around confirmed sync backend; fix bug #1 (pgrep/pkill pattern) while doing so, or drop the daemon tools if a background sync process isn't actually wanted going forward.
4. kg-session-audit: needs a real query against Session+Violation/Escalation edges (§6), not OrchestrataSession/IN_SESSION.
5. Drop code-review/code-fix tools in favor of exposing scripts/code-review.py (with --fix) as a tool wrapper instead of reimplementing checks inline.

W4 — build the conversation-tracking subsystem from scratch (US-007, independently schedulable, no dependency on W1-W3 other than the Redis queue key convention)

1. Design Conversation/ConversationTurn/HAS_TURN additions to canonical_schema.py (per this project's own "ontology before graph import" rule — design the schema addition before writing any ingestion code).
2. Build the queue consumer (fixing bug #2's invalid Cypher while doing so).
3. Wire conv-sync/conv-status/conv-query tools against it.

Deprioritize / consider dropping rather than porting:

• enforceTestingPolicy/enforceImportPolicy/enforceDevelopmentPolicy (OBSOLETE/SUPERSEDED, §3.2) — do not reimplement; if OpenCode-side enforcement is wanted at all, it should shell out to the existing .claude/hooks/* logic or code-review.py's BANNED-DEP gate rather than maintaining a second regex set.
• checkMcpHealth / MCP document-reader/writer awareness — no such MCP servers exist in ultimate's tool registry; either build them first (separate spec) or drop this check.
• session.status hook — lowest value of the 5 dead hooks (pure toast notification); probably not worth resurrecting even after the event rewrite.

Related

• Plans
• Orchestrata Ultimate — project index
• Workflow
• Tasks