mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-10-27 06:53:11 +08:00
Brings the Atlas branch up to current main (7b0f553c). Eight files
conflicted; how each was settled:
- src/mcp/mcp.c: the real ingest_traces description stays, in main's tool
row shape (main dropped the title column); index_repository keeps the
truthful abort branches (aborted_previous_preserved, persist_failed)
and gains main's format_migration flag in the success branch.
- src/ui/http_server.c and tests/test_httpd.c: the branch's twelve-tool
read allowlist for /rpc (#1663) over main's three, with main's %zu
and initialised counter.
- README.md: main's surface count (45), the branch's Atlas line.
- graph-ui (the previous frontend, replaced by the stacked #2068 but
kept building and green here): the branch's node-selection wiring
(onSelectNode) is kept consistently, so main's duplicate
handleSelectPath and its 3-argument call go; main's version chip is
added to the branch's header; useProjects keeps the branch's
render-first flow on top of main's paginated JSON helpers
(fetchAllProjects, fetchFullSchema), which the lean output contract
requires, and a project whose size the server did not send now gets
its schema too. main's GraphTab.selection.test.tsx, written against
main's GraphTab, is dropped in favour of the branch's own #1197
coverage in GraphTab.regions.test.tsx ("reports selected nodes to
the route for deep links"); main's useProjects pagination test waits
for the lazy schema enrichment instead of asserting before it runs.
Verified: mcp, httpd and ui suites 414 passed; the old frontend builds
and its 149 tests pass.
Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
test-infrastructure/ — the local venues
The local half of the 3-OS CI ladder. Every leg here runs the SAME canonical
scripts CI runs (scripts/test.sh, build.sh, smoke-local.sh,
soak-legs.sh, vm-smoke.sh — see scripts/README.md); this directory only
provisions containers and the Windows VM. The venue-parity contract
(tests/test_venue_parity_contract.sh, Step 0j of every test leg) fails the
build if a venue grows its own harness logic — here or in the workflows.
Entry points
| venue | entry | notes |
|---|---|---|
| Linux (arm64 + amd64) + cross-compile | ./run.sh <leg> (--help for the leg list) |
Colima only — Docker Desktop is broken on this machine. A clean-disk preflight (scripts/ci/preflight-docker.sh) runs before every leg: GitHub runners are ephemeral with a known-free 14 GB disk, so the long-lived VM is swept back to that shape first. |
| Real Windows (UTM ARM64 VM) | vm/win.sh <command> (win.sh help) |
Same preflight idea (scripts/ci/clean-test-residue.ps1), plus CI's protected per-user TEMP root. Wine (run.sh windows) is a compile check only — never a substitute for the VM. |
| macOS | run the canonical scripts natively | scripts/test.sh, scripts/build.sh, scripts/smoke-local.sh … |
The ladder (before any push)
scripts/test.sh— macOS native (or--suites …while iterating)./test-infrastructure/run.sh full— Linux arm64 test/build/TSan/smoke/portable + mingw cross-compile (+amd64,soak-linuxas needed)vm/win.sh test-par·guards·smoke-install·soak— the real-Windows legs
Infra unavailable = a run blocker to escalate — never a silent bypass.
Fidelity guarantees (what makes local predictive of CI)
- Same scripts, same sequence, same flags — platform specifics (e.g. the CLANGARM64 trap-UBSan default) live inside the canonical entries, applied identically everywhere.
- Same environment shape — protected TEMP roots, sandboxed smoke, clean builds with the content-verified ccache (a hit is byte-identical to a cold compile; caches only accelerate, never change results).
- Same starting disk — preflights sweep residue and BLOCK below the runner's 14 GB floor (a quietly full disk fails inside install paths and masquerades as a product bug).
- Known, deliberate residuals — runner physics (4 vCPU vs local cores, shared tenancy), Defender ON in the VM vs OFF on GitHub runners, no TSan on Windows anywhere, no ASan runtime on native ARM64 Windows (trap-UBSan + PageHeap stand in).
See vm/README.md for VM provisioning and day-to-day VM mechanics.