Knowledge Wiki Orchestrata Ultimate

Orchestrata Ultimate › Research › DeepChat history review

DeepChat history review (2026-10-11 to 2026-10-21)
Question What did the DeepChat agent sessions do to these repos and this host, and which of it is still in effect or still open?
Method Read the extracted DeepChat transcripts: seven conversation exports (three of them empty stubs), plus longer extracts of the work-machine session and the components session. Each claim was then checked against git, the file system or unit state on 2026-10-23. Only technical content is recorded here
Status Reviewed. The dependency-injection ruling is acted on (a5c419f5). The 16 disabled units and the 48 untracked skills are open

The sessions

Dates Session What it was about
10-11 "analyze my orchestrata.codetools project" An architecture diagram of codetools (short)
10-20 05:26–07:37 "Greeting and codetools assistance offer" Writing DeepChat skills
10-20 07:37–08:59 "Review this week's notes and identify gaps" The codetools weekly review, a Qwen worker lane, the codetools plugin, the work-machine install plan, and the dependency-injection ruling
10-21 00:31–19:37 "Opening wt-COMPONENTS" Pushes to master, the RAG investigation, gate work, a Memgraph query benchmark, the btrfs diagnosis and the shutdown

1. The codetools Claude Code plugin (2026-10-20)

Mohamed asked for a version of codetools he could install on a work computer with only Claude Code. He set the shape: "not an MCP, a plugin", on Python 3.14t, "also Prolog included and skills and hooks".

The plugin went into orchestrata.codetools as commit 84ec9bd7 and is still on disk under plugins/codetools/:

The same session also committed the codetools weekly review (b4a46b64) and an ADR index (4abe9beb).

The session installed the plugin live, and claude plugin install reported outcome: ok. Its hook smoke tests passed, but they fed the hooks hand-built payloads. Today's hook inventory found that the real PreToolUse payload nests content and file_path under tool_input. In live sessions, therefore:

The plugin is installed with scope local for ~/workspace only.

A lesson from the same session. The Qwen3 Coder Next worker was asked to write the ADR index, and it produced a canned index with wrong titles, dates and statuses. The coordinator rejected it and regenerated the index deterministically from the 44 ADR files. For pure extraction, a script beats a model. The components swarm page records the same lesson at larger scale.

2. The work-machine install plan and the janus-swi blocker

The plan is in orchestrata.codetools/plans/claude-code-only-install-2026-10-20.md: build the wheel set on Python 3.14t, ship the plugin tree, uv tool install, then claude plugin install.

The live smoke test hit a blocker: uv tool install codetools --python 3.14t failed. The chain was:

  1. codetools depended on orchestrata-ultimate, which is a git dependency that only resolves on 3.14;
  2. orchestrata-ultimate pulls its vendored, patched janus-swi as a source build;
  3. that build needs SWIPL (ADR-0091), and with it set it still fails against the Guix swipl 9.3.8, because of split libswipl.so paths and a gcc pointer-type error in janus.c.

The session tried three overrides: [tool.uv] override-dependencies, a [tool.uv.sources] index override, and an explicit index declaration. uv tool install --from honoured none of them for the transitive build. The session then established that codetools only needs the pure-Python orchestrata_ultimate.openspec reader. It proposed making that dependency optional, with pre-built wheels or Python 3.13 as the alternatives.

Whether the work-machine install now succeeds end to end was not measured after the fix in section 3.

3. The dependency-injection ruling

Mohamed, 2026-10-20 08:59: "YES, USE DEPENDENCY INJECTION".

It was implemented on 2026-10-22 as codetools a5c419f5, "spec intake: inject the OpenSpec reader; orchestrata-ultimate becomes the openspec extra". It was deployed by ct-install 75, with 20 of 20 tests passed. orchestrata.codetools/pyproject.toml now reads: "The OpenSpec parser codetools.spec reads changes with, injected into read_requirements (Mohamed, 2026-10-20). Not needed to install or run." The change also removes the codetools to orchestrata-ultimate cycle (see Python deployment best practices).

4. 2026-10-21: pushes, gate fixes and the RAG investigation

These commits are all on origin/master (checked 2026-10-23):

The RAG and context-injection investigation was published as RAG context-injection investigation.

The "fix the batch" diagnosis went no further than a diagnosis. In an affected run of 151 modules, 137 fast modules were killed when a slow Memgraph module in the same bin blew the 420 s batch timeout. The duration cache holds contention-free times, so the bin packer under-provisioned the bins. It was not fixed in that session.

The session also "fixed" three except A, B: clauses in wt-COMPONENTS/scripts/run_tests.py (5a935740e), calling them "Python-2 syntax". On Python 3.14 the unparenthesised form is valid (PEP 758). The same form is still in wt-MAP-PRECOMMIT/scripts/run_tests.py (in _write_canonical_report, for example), and the deployed AST toolkit parses it without error. The diagnosis was wrong; the parenthesised rewrite is harmless.

5. 2026-10-21: the Memgraph benchmark, the btrfs diagnosis and the shutdown

The query benchmark. 50 graph queries were run against prod at three scopes (1 module, 3 modules, all modules), before and after the rewrites. Most rewrites returned the same result much faster on the narrow scopes. Two examples: "total CALLS edges" at all modules went from 32,743 ms to 969 ms, and "parameters" at 3 modules from 4,101 ms to 35 ms. Two rewrites changed the results and are therefore not equivalent:

The extract does not show these two being reconciled.

The slowness. The diagnosis was storage, not queries. Memgraph's data sat in the Incus btrfs pool on the Samsung T9 portable USB SSD (/dev/sda2). There:

The root cause found afterwards was full btrfs qgroups on the T9 pool. Switching to simple quotas took sync from 60 s to 5 ms (see T9 Incus btrfs qgroup stall).

The shutdown. On Mohamed's instruction, DeepChat stopped:

It also stopped and disabled 16 units:

Load dropped from about 14.7 to 6.77.

State on 2026-10-22/23. The units are still disabled. orchestrata-conversation-consumer and the user gitlab-runner were active even though they were disabled, and the system gitlab-runner was also active (see host inventories). The test and dev fleets still have autostart off. Re-enabling the units awaits Mohamed.

6. 48 new skills in wt-COMPONENTS

On 2026-10-20 DeepChat wrote skills tailored to itself. The topics included incus, uv, Python best practices, pytest, Memgraph, graph and ontology design, Redis, Wiki.js, system design, Azure, GCP, direnv, Prolog, Terraform/OpenTofu, C, CPython, tracing, traceability, OpenSpec, project management, documentation, Linux services, Emacs, rclone, Todoist, taskwarrior, Claude Code, algorithms, GoF patterns, requirements analysis and git workflow. There were more.

Measured 2026-10-23:

Whether to commit, prune or move the 48 untracked skills has not been decided.

What is still open from DeepChat's work

  1. The 16 disabled units, and autostart on the test and dev fleets. Awaiting Mohamed.
  2. The 48 untracked skills in wt-COMPONENTS.
  3. Three codetools plugin hooks that do nothing, and one that can loop (see host inventories).
  4. The batch-packing starvation diagnosed on 2026-10-21. Not fixed in that session; current status not measured.
  5. Benchmark queries #39 and #40, whose rewrites changed results.
  6. An end-to-end test of the work-machine install after a5c419f5.