ruvnet / ruvnet/RuVector

[PIR][WP1] Adopt LatentMesh ADR-009's control loop as the runtime spine; open cross-repo coordination

Open
#848 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

adr cross-repo phase-0 pir
Dominant language
Rust
Stars
4.5k
Forks
603
Avg merge
23h 32m
Merged PRs (30d)
59

Description

Epic: #837 · Cross-repo counterpart: ruvnet/LatentMesh#2 · Plan: docs/research/perpetual-intelligence-runtime/03-program-plan.md

Goal

Formally adopt LatentMesh ADR-009's control loop as this program's architecture, and open a standing coordination thread with LatentMesh maintainers so ruvector-side work (WP5) does not diverge from LatentMesh's own evolving design.

execute -> transfer latent state -> counterfactual audit (ADR-003) -> measure causal value
        -> update edge value/authority ceiling (ADR-008) -> persist (ADR-005)
        -> change topology (ADR-006, Darwin) -> next execution

ADR-009 (Status: Proposed, 2026-08-18) states its own gap: "The statistical primitive (ADR-003) and admission gate (ADR-008) are implemented; the closed loop across live components is not wired."

Prior art this adopts — both repos, not just one

ruvnet/autogenous ADR-401 "The Perpetual Intelligence Machine" (Status: Accepted, 2026-08-16) already defines this program's concept, with a 10-capability Built/Partial/Gap map, the operating loop, and an acceptance test. ADR-400 (Accepted — implemented, first flywheel turn measured) and ADR-403 (verifiable execution loop, Accepted) are further along still.

PIR extends autogenous ADR-401 + LatentMesh ADR-009 and closes their declared gaps. It does not re-derive them. The adopting ADR must cite both and must not present their content as novel.

Grounding facts that change what "adopt" means:

  • LatentMesh is ~1,407 LOC across 23 tests, with no network transport crate. Adopting ADR-009 means adopting a design contract, not inheriting a codebase.
  • The real autogenous implementation is TypeScript in packages/radio-moe/ (~6.2K LOC src + 3.2K test), not its Rust crates.
  • ruvector has zero existing wiring to either repo today — only an unmerged origin/docs/link-latentmesh branch stub.
  • autogenous ADR-400/401 reference a metaharness ADR-322 that is currently unlocated. Do not cite it as though its contents are known until it is found.

Acceptance criteria

  • A coordination doc/thread exists and is linked from both epics (#837 and ruvnet/LatentMesh#1).

  • A new ADR (numbered post-WP0a, above the true max of 304) formally adopts the loop, cites autogenous ADR-401/400/403 and LatentMesh ADR-001–009 as the prior art being extended, and contradicts neither.

  • Each of the seven loop stages is mapped to an owning work package and repo; any stage with no owner is flagged explicitly rather than left implicit.

  • The six governing invariants are mapped onto loop stages, so each has a named enforcement point.

  • A lightweight release-train coordination doc tracks version compatibility across the five repos. ruvector must not pin to unreleased commits of the others without an explicit compatibility ADR.

  • Cross-repo ADR citation convention established: always name the repo.

  • A "verify against fix history" step is part of the coordination protocol. Every inherited claim of the form "known bug", "gap", or "not yet implemented" must be checked against git log of the named path plus upstream release notes before it enters this program's scope. An inherited status claim is a hypothesis, not a fact.

    Rationale — this is a systemic finding, not a hypothetical. All three blocking errors in PR #847 shared this single root cause:

    Stale claim Reality
    autogenous ADR-401 capability row stale
    dream-machine ADR-0001's citation of metaharness ADR-251 dead citation — the artifact exists (docs/dream-cycle/), only the ADR form was wrong
    ruvector ADR-259's "307 bug blocks live-serve" already fixed in the same PR that wrote it (#590, commit 946275a61)

    A fourth instance surfaced independently in #855 and has since been resolved the same way as ADR-103 and ADR-322: METAHARNESS-README's ADR-150 attribution was treated as an unverified upstream metaharness doc, when it is in fact ruvnet/ruflo ADR-150 (v3/docs/adr/ADR-150-metaharness-integration-surfaces.md, Implemented, 2026-06-16). ruvector's own ADR-150 is an unrelated pi-brain/Tailscale ADR.

    That is three separate ADR numbers — 103, 150, 322 — each of which turned out to be ruflo's and was cited without a repo qualifier. The pattern is not incidental: an unqualified ADR number in a multi-repo org is ambiguous by construction. Repo-qualified citation is the structural fix, and it belongs in the coordination protocol alongside the fix-history check.

    Documents record what was true when written and are rarely revised when the underlying bug is fixed — ADR-259's case is the sharpest, since the "blocked" wording and the fix landed in the same pull request. Treat every inherited status claim in 02-asset-map.md and in sibling-repo ADRs as needing this check.

Dependencies

WP0a (#845) — ADR numbering must be clean before this program allocates its own numbers. Blocks WP2, WP3, WP5, WP8.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/research/perpetual-intelligence-runtime/03-program-plan.md, epic #837, WP0a #845, and the referenced ADRs in RuVector, autogenous, and LatentMesh. Verify inherited status claims with git log for each named path and upstream release notes, then produce the coordination thread, cross-repo ADR, loop and invariant ownership map, release-train document, and citation convention described in the acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, rust, typescript
Domain
distributed-systems, documentation, release
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.