conexus 6.3.2__tar.gz → 6.3.3__tar.gz

{conexus-6.3.2 → conexus-6.3.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: conexus
-Version: 6.3.2
+Version: 6.3.3
 Summary: Self-hosted semantic search and knowledge management for LLM-driven development
 Project-URL: Homepage, https://github.com/Hellblazer/nexus
 Project-URL: Repository, https://github.com/Hellblazer/nexus
@@ -49,6 +49,8 @@ Description-Content-Type: text/markdown
 
 # Nexus
 
+**Persistent memory and semantic search for Claude.** Three storage tiers that survive across sessions, an event-sourced document catalog with typed links, and a specification-before-code workflow for tracking decisions. Local-first; no API keys required. Knowledge compounds across conversations instead of evaporating when the window closes.
+
 [![CI](https://github.com/Hellblazer/nexus/actions/workflows/ci.yml/badge.svg)](https://github.com/Hellblazer/nexus/actions/workflows/ci.yml)
 [![PyPI version](https://img.shields.io/pypi/v/conexus)](https://pypi.org/project/conexus/)
 [![Python versions](https://img.shields.io/pypi/pyversions/conexus)](https://pypi.org/project/conexus/)
@@ -58,8 +60,6 @@ Description-Content-Type: text/markdown
   <img src="https://i0.wp.com/tensegrity.blog/wp-content/uploads/2026/04/a-stately-pleasure-dome.png?w=480&ssl=1" alt="A brass-ribbed crystal dome on a hilltop at dusk" align="right" width="320" />
 </a>
 
-**Persistent memory and semantic search for Claude.** Three storage tiers that survive across sessions, an event-sourced document catalog with typed links, and a specification-before-code workflow for tracking decisions. Local-first; no API keys required. Knowledge compounds across conversations instead of evaporating when the window closes.
-
 **Start here**: [**How I actually use Nexus**](https://tensegrity.blog/2026/04/26/how-i-actually-use-nexus/) — the conceptual overview and the shape of the substrate. Then [**Installing Nexus**](https://tensegrity.blog/2026/04/26/installing-nexus/) — a ten-minute hands-on walkthrough from `uv tool install` through your first search.
 
 ## Prerequisites
@@ -111,7 +111,9 @@ nx index repo .                                            # index your repo + d
 nx search "how does retry work"                            # semantic search, fully local
 ```
 
-`nx init` provisions the bundled Postgres 17 + pgvector cluster, fetches the bge-768 ONNX model the service embeds with, starts the persistent service, and offers to register the OS autostart unit so it restarts at login/boot (prompt defaults to yes; `--yes` accepts non-interactively, `--no-autostart` starts a session supervisor only). There is **no** separate `nx daemon t2 install` step — T2 (notes/plans) is served by the same service in the default config. The permanent vector store (T3) serves through this native service; the bundled binary + Postgres are cosign-verified and acquired automatically (see [Getting Started](https://github.com/Hellblazer/nexus/blob/main/docs/getting-started.md) for the full flow). (The older `nx init --service` flag still works but is deprecated — plain `nx init` is the path now.) **First run only:** this downloads a few hundred MB (the signed ~134 MB service binary, the relocatable Postgres bundle, and the ~140 MB bge-768 model) and takes a few minutes; subsequent starts are fast.
+Pick `<engine-service-vX.Y.Z>` from the [engine-service releases](https://github.com/Hellblazer/nexus/releases) (the newest `engine-service-v*` tag) — there is no `latest` resolution, the tag is explicit. You can instead export `NEXUS_SERVICE_TAG=engine-service-vX.Y.Z`, in which case `nx init` acquires the binary itself and the explicit `install-binary` step is optional.
+
+`nx init` provisions the bundled Postgres 17 + pgvector cluster, fetches the bge-768 ONNX model the service embeds with, starts the persistent service, and offers to register the OS autostart unit so it restarts at login/boot (prompt defaults to yes; `--yes` accepts non-interactively, `--no-autostart` starts a session supervisor only). There is **no** separate `nx daemon t2 install` step — T2 (notes/plans) is served by the same service in the default config. The permanent vector store (T3) serves through this native service; the bundled binary + Postgres are cosign-verified and acquired automatically. `nx init` is idempotent — safe to re-run. (The older `nx init --service` flag still works but is deprecated — plain `nx init` is the path now.) **First run only:** this downloads a few hundred MB (the signed ~134 MB service binary, the relocatable Postgres bundle, and the ~140 MB bge-768 model) and takes a few minutes; subsequent starts are fast.
 
 > **Upgrading from a pre-6.0 install?** 6.0 moves the permanent vector store from ChromaDB to the Postgres + pgvector service. After `uv tool upgrade conexus`, run **`nx guided-upgrade`** — one command detects your existing store, provisions and version-pins the service, and migrates your data with validation and copy-not-move rollback safety. Your ChromaDB data is left intact as the migration source.
 

{conexus-6.3.2 → conexus-6.3.3}/README.md

@@ -1,5 +1,7 @@
 # Nexus
 
+**Persistent memory and semantic search for Claude.** Three storage tiers that survive across sessions, an event-sourced document catalog with typed links, and a specification-before-code workflow for tracking decisions. Local-first; no API keys required. Knowledge compounds across conversations instead of evaporating when the window closes.
+
 [![CI](https://github.com/Hellblazer/nexus/actions/workflows/ci.yml/badge.svg)](https://github.com/Hellblazer/nexus/actions/workflows/ci.yml)
 [![PyPI version](https://img.shields.io/pypi/v/conexus)](https://pypi.org/project/conexus/)
 [![Python versions](https://img.shields.io/pypi/pyversions/conexus)](https://pypi.org/project/conexus/)
@@ -9,8 +11,6 @@
   <img src="https://i0.wp.com/tensegrity.blog/wp-content/uploads/2026/04/a-stately-pleasure-dome.png?w=480&ssl=1" alt="A brass-ribbed crystal dome on a hilltop at dusk" align="right" width="320" />
 </a>
 
-**Persistent memory and semantic search for Claude.** Three storage tiers that survive across sessions, an event-sourced document catalog with typed links, and a specification-before-code workflow for tracking decisions. Local-first; no API keys required. Knowledge compounds across conversations instead of evaporating when the window closes.
-
 **Start here**: [**How I actually use Nexus**](https://tensegrity.blog/2026/04/26/how-i-actually-use-nexus/) — the conceptual overview and the shape of the substrate. Then [**Installing Nexus**](https://tensegrity.blog/2026/04/26/installing-nexus/) — a ten-minute hands-on walkthrough from `uv tool install` through your first search.
 
 ## Prerequisites
@@ -62,7 +62,9 @@ nx index repo .                                            # index your repo + d
 nx search "how does retry work"                            # semantic search, fully local
 ```
 
-`nx init` provisions the bundled Postgres 17 + pgvector cluster, fetches the bge-768 ONNX model the service embeds with, starts the persistent service, and offers to register the OS autostart unit so it restarts at login/boot (prompt defaults to yes; `--yes` accepts non-interactively, `--no-autostart` starts a session supervisor only). There is **no** separate `nx daemon t2 install` step — T2 (notes/plans) is served by the same service in the default config. The permanent vector store (T3) serves through this native service; the bundled binary + Postgres are cosign-verified and acquired automatically (see [Getting Started](https://github.com/Hellblazer/nexus/blob/main/docs/getting-started.md) for the full flow). (The older `nx init --service` flag still works but is deprecated — plain `nx init` is the path now.) **First run only:** this downloads a few hundred MB (the signed ~134 MB service binary, the relocatable Postgres bundle, and the ~140 MB bge-768 model) and takes a few minutes; subsequent starts are fast.
+Pick `<engine-service-vX.Y.Z>` from the [engine-service releases](https://github.com/Hellblazer/nexus/releases) (the newest `engine-service-v*` tag) — there is no `latest` resolution, the tag is explicit. You can instead export `NEXUS_SERVICE_TAG=engine-service-vX.Y.Z`, in which case `nx init` acquires the binary itself and the explicit `install-binary` step is optional.
+
+`nx init` provisions the bundled Postgres 17 + pgvector cluster, fetches the bge-768 ONNX model the service embeds with, starts the persistent service, and offers to register the OS autostart unit so it restarts at login/boot (prompt defaults to yes; `--yes` accepts non-interactively, `--no-autostart` starts a session supervisor only). There is **no** separate `nx daemon t2 install` step — T2 (notes/plans) is served by the same service in the default config. The permanent vector store (T3) serves through this native service; the bundled binary + Postgres are cosign-verified and acquired automatically. `nx init` is idempotent — safe to re-run. (The older `nx init --service` flag still works but is deprecated — plain `nx init` is the path now.) **First run only:** this downloads a few hundred MB (the signed ~134 MB service binary, the relocatable Postgres bundle, and the ~140 MB bge-768 model) and takes a few minutes; subsequent starts are fast.
 
 > **Upgrading from a pre-6.0 install?** 6.0 moves the permanent vector store from ChromaDB to the Postgres + pgvector service. After `uv tool upgrade conexus`, run **`nx guided-upgrade`** — one command detects your existing store, provisions and version-pins the service, and migrates your data with validation and copy-not-move rollback safety. Your ChromaDB data is left intact as the migration source.
 

{conexus-6.3.2 → conexus-6.3.3}/docs/README.md

@@ -2,6 +2,8 @@
 
 Start with [Getting Started](getting-started.md) for installation. Then explore by topic.
 
+`docs/*.md` is living reference documentation — kept current with the codebase and safe to trust as-is. `docs/rdr/*.md` is a different thing entirely: an append-only historical decision log (186+ files) capturing the reasoning behind past design choices, some since superseded. If you're looking for a how-to or a current design reference, stay in `docs/`; only dig into `docs/rdr/` when you need the "why" behind a decision.
+
 ## Core
 
 - [Getting Started](getting-started.md) — Install, local usage, Claude Code plugin
@@ -50,6 +52,8 @@ Start with [Getting Started](getting-started.md) for installation. Then explore
 - [`field-reports/`](field-reports/) — Production shakeout reports
 - [`operations/`](operations/) — Operator runbooks
 - [`plans/`](plans/) — Historical implementation plans
+- [`testing/`](testing/) — Plugin surface coverage matrices and testing artifacts
+- [`proposals/`](proposals/) — Standalone application proposals and design write-ups
 
 ## Claude Code Plugins
 

{conexus-6.3.2 → conexus-6.3.3}/docs/rdr/README.md

@@ -1,4 +1,4 @@
-**Reading order:** [Overview](../rdr-overview.md) | [Workflow](../rdr-workflow.md) | [Nexus Integration](../rdr-nexus-integration.md) | [Templates](../rdr-templates.md) | RDR Index (this page)
+**Reading order:** [Overview](../rdr.md#rdr-research-design-review) | [Workflow](../rdr.md#workflow) | [Nexus Integration](../rdr.md#nexus-integration) | [Templates](../rdr.md#rdr-template) | RDR Index (this page)
 
 ---
 
@@ -6,16 +6,16 @@
 
 An RDR (Research-Design-Review) is a short document that records a technical decision: the problem, what was found, what was chosen, and what was rejected. They exist so decisions are reproducible, searchable, and useful as agent context. Each RDR is written once and never deleted — closing an RDR means updating its status, not removing it.
 
-**New to RDR?** Start with the [Overview](../rdr-overview.md) — it covers when to write one, how to right-size it, and evidence classification. Then read the [Workflow](../rdr-workflow.md) for the full lifecycle.
+**New to RDR?** Start with the [Overview](../rdr.md#rdr-research-design-review) — it covers when to write one, how to right-size it, and evidence classification. Then read the [Workflow](../rdr.md#workflow) for the full lifecycle.
 
 ## Process Documentation
 
 | Doc | What it covers |
 |-----|---------------|
-| [Overview](../rdr-overview.md) | What RDRs are, when to write one, evidence classification, the iterative pattern |
-| [Workflow](../rdr-workflow.md) | Create → Research → Gate → Accept → Close, with worked example |
-| [Nexus Integration](../rdr-nexus-integration.md) | How storage tiers (T2/T3) and agents amplify RDRs |
-| [Templates](../rdr-templates.md) | Minimal and full RDR examples, post-mortem template, drift taxonomy |
+| [Overview](../rdr.md#rdr-research-design-review) | What RDRs are, when to write one, evidence classification, the iterative pattern |
+| [Workflow](../rdr.md#workflow) | Create → Research → Gate → Accept → Close, with worked example |
+| [Nexus Integration](../rdr.md#nexus-integration) | How storage tiers (T2/T3) and agents amplify RDRs |
+| [Templates](../rdr.md#rdr-template) | Minimal and full RDR examples, post-mortem template, drift taxonomy |
 
 ---
 
@@ -201,4 +201,4 @@ An RDR (Research-Design-Review) is a short document that records a technical dec
 
 ---
 
-**Reading order:** [Overview](../rdr-overview.md) | [Workflow](../rdr-workflow.md) | [Nexus Integration](../rdr-nexus-integration.md) | [Templates](../rdr-templates.md) | RDR Index (this page)
+**Reading order:** [Overview](../rdr.md#rdr-research-design-review) | [Workflow](../rdr.md#workflow) | [Nexus Integration](../rdr.md#nexus-integration) | [Templates](../rdr.md#rdr-template) | RDR Index (this page)

{conexus-6.3.2 → conexus-6.3.3}/mcpb/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "conexus-mcpb"
-version = "6.3.2"
+version = "6.3.3"
 description = "Conexus packaged as Claude Desktop .mcpb (Desktop Extension)"
 requires-python = ">=3.12"
 dependencies = [
@@ -10,7 +10,7 @@ dependencies = [
     # while collections are indexed at 768/1024-dim, so every T3 search hits a
     # dimension mismatch and returns zero results. The .mcpb cannot run the
     # interactive `nx init` embedder choice, so it must pin [local] explicitly.
-    "conexus[local]>=6.3.2",
+    "conexus[local]>=6.3.3",
 ]
 
 [tool.uv]

{conexus-6.3.2 → conexus-6.3.3}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "conexus"
-version = "6.3.2"
+version = "6.3.3"
 description = "Self-hosted semantic search and knowledge management for LLM-driven development"
 readme = { file = "README.md", content-type = "text/markdown" }
 requires-python = ">=3.12,<3.14"

{conexus-6.3.2 → conexus-6.3.3}/src/nexus/commands/collection.py

@@ -398,6 +398,16 @@ def reindex_cmd(name: str, force: bool) -> None:
         if rdr_files:
             click.echo(f"Re-indexing {len(rdr_files)} RDR documents...")
             try:
+                # nexus-3lswy: this single-collection reindex is intentionally
+                # separate from `nx index repo`'s RDR path (which now routes
+                # through indexer._run_index's 4th run_file_loop category via
+                # _index_prose_file). batch_index_markdowns calls
+                # doc_indexer._catalog_markdown_hook, which registers under a
+                # SEPARATE "curator" catalog owner — safe here because this
+                # command never also runs indexer._catalog_hook's batched
+                # register_many pass for these files. Do not add that pass
+                # here without also dropping this call, or the RDR
+                # double-registration bug nexus-3lswy fixed comes back.
                 batch_index_markdowns(
                     rdr_files, corpus=corpus, collection_name=name, force=True
                 )