Compute Fabric G1: stable local host identity + Host Capability Snapshot v1

[James3014]

Status

P0 — READY_NOW / DIRECT_CANONICAL bounded implementation
AUTO_CHAIN=false.

Parent product contract: James3014/Nexus-new#1061.

Fresh source watermark at creation:

• DevSpace main: 1f1ec9465dbb8edd0c67c91faee5d406878322ac
• P0: implement thin DevSpace -> HerdR external-agent runtime gateway #236 HerdR gateway: completed/merged/post-merge verified
• P0: fix ChatGPT↔DevSpace caller continuity, live tool projection, and evidence-chain liveness #240 caller/projection continuity: completed
• P0: cut over DevSpace local-agent lifecycle to HerdR production backend #242 HerdR production cutover: separate active lane; this Issue must avoid its lifecycle/cutover mutation surface.

Goal

Make DevSpace the canonical physical-host fact source required by Compute Fabric Placement without adding scheduling/placement authority.

Provide a truthful HostCapabilitySnapshot v1 that works in the default one-host case with zero fabric-specific configuration and can later support explicit 1..N host inventory.

Ownership boundary

DevSpace owns:

• persistent physical hostId;
• static host facts;
• dynamic host telemetry/readback;
• verified DevSpace identity/capability facts;
• snapshot identity, observation time and freshness inputs.

DevSpace does not own:

• CapabilityPlanner route/capability selection;
• host placement/filter/score policy;
• PlacementDecision / HostPlacementLease;
• retry/failover permission;
• verification/acceptance;
• a second task/workspace/operation ledger.

Required semantics

1. Persistent local physical host identity

• hostId must survive DevSpace process restart.
• hostId != serverInstanceId.
• current serverInstanceId remains ephemeral runtime identity.
• no machine-specific James/M1/M4/M5 identity may be encoded in product logic.
• identity storage must stay owner-controlled and outside project/workspace authority.

2. Zero-config singleton host snapshot

When DEVSPACE_PHYSICAL_HOST_REGISTRY is absent, DevSpace must still expose one truthful local host snapshot.

No separate LocalPlacementEngine and no requirement that a single-machine user configure a physical host registry.

Remote/explicit Host Registry behavior from #123 remains additive and unchanged.

3. Three-layer capability model

Snapshot must separate:

• static facts: hostId, architecture/OS, memory class/total memory and other stable physical facts supported by current host;
• dynamic state: free/available memory, load/CPU pressure or other bounded observable telemetry, connectivity/readiness freshness;
• verified capabilities: current DevSpace source/build identity and devspace.capability_manifest.v1 identity/readback.

Dynamic telemetry MUST NOT mutate or be hashed into capability_manifest.v1; that manifest remains verified MCP tool/schema identity.

4. Snapshot identity/freshness

Expose enough bounded metadata to distinguish:

• physical host identity;
• runtime/server generation;
• verified capability-manifest identity;
• telemetry observation generation/time.

A later placement consumer must be able to reject stale observations without treating telemetry as authority.

Initial bounded implementation surface

Prefer the smallest current-source surface around:

• src/physical-host-registry.ts
• src/build-identity.ts
• a new narrow host-capability snapshot module if required
• corresponding focused tests
• minimal server/config registration wiring only if required to expose read-only snapshot

Do not touch #242 HerdR/local-agent lifecycle/cutover files unless a fresh unavoidable dependency is physically proven first.

Required controls

Positive:

1. no registry configured -> exactly one local snapshot available;
2. restart -> same hostId, different serverInstanceId permitted;
3. static/dynamic/verified layers are separately readable;
4. dynamic telemetry change does not change capabilityManifestSha256;
5. explicit remote registry continues to work.

Negative:

1. malformed/stale persistent host identity fails closed rather than silently minting conflicting authority;
2. no telemetry field can grant mutation/execution authority;
3. no host snapshot action performs remote execution;
4. no serverInstanceId substitution for persistent hostId;
5. no duplicate local + explicitly configured same-host identity without an explicit deterministic contract.

Verification

At minimum:

• focused unit tests for host identity/snapshot;
• existing physical-host-registry tests;
• typecheck;
• production build;
• git diff --check;
• exact changed-path audit;
• restart identity witness on the M5 host if the source Candidate reaches host-verification state.

Claim ceiling

Maximum before independent review/integration:

DEVSPACE_HOST_CAPABILITY_SNAPSHOT_V1_CANDIDATE_READY

No merge/deploy/cutover/placement authority is granted by this Issue.

[James3014]

G1 implementation status — required verifiers PASS; Candidate formation blocked by #240 regression

Exact implementation subject:

• source HEAD: 1f1ec9465dbb8edd0c67c91faee5d406878322ac
• source tree: a224ca6afb1b51030430206dfda022be4a06adfe
• workspace: ws_1a29266dae
• Core session: cms_73b3933c5d8345d9a1dd62fe594d3b52
• binding hash: sha256:a351726a532b664767a8da9fd4a7cfd185e7f1d7a68897a5a2923a48c87d4f09

Exact dirty paths only:

• src/server.ts
• src/host-capability-snapshot.ts
• src/host-capability-snapshot.test.ts

No #242 HerdR/local-agent lifecycle/cutover file is modified.

Implemented behavior

• persistent physical hostId stored under DevSpace owner state and reused across independent Node process generations;
• hostId remains distinct from rotating serverInstanceId;
• malformed persistent host identity fails closed rather than silently minting a new identity;
• zero-config read-only host_capability_snapshot MCP surface is registered even when DEVSPACE_PHYSICAL_HOST_REGISTRY is absent;
• explicit remote Host Registry remains separate/additive and unchanged;
• snapshot physically separates:
  • static host facts;
  • dynamic telemetry + LOCAL_OBSERVED connectivity;
  • verified DevSpace runtime/capability-manifest identity;
• telemetry has its own digest and does not modify devspace.capability_manifest.v1;
• snapshot carries snapshotId, observedAt, and telemetry digest;
• the new tool is automatically included in the existing MCP tool-catalog generation via the physical registration inventory.

Required verification

host-capability-snapshot.test.ts   8/8 PASS
physical-host-registry.test.ts    6/6 PASS
npm run typecheck                 PASS
npm run build                     PASS
git diff --check                  PASS
restart identity witness          PASS (two separate Node processes, same state dir)
targeted createServer regressions PASS

Current file SHA-256:

• src/server.ts: 03eaeabe515c1f6ddb78e45b5c52ef9b282fb950c06468309044bea3d1b50469
• src/host-capability-snapshot.ts: 4724283fa369b09418f49131aa5718c30e3613aa7b689cefdb3d113642a0c141
• src/host-capability-snapshot.test.ts: 8b17828de5480dbb1f6b1b73a5b1ee86a236050ef7d53aa7972cf37354ebc535

Extra full-suite observation

An extra npm test run reached one unrelated existing environment/fixture failure in src/local-agent-toolchains.test.ts:

• the test copies process.execPath into a temp directory;
• current Homebrew Node is dynamically linked to @rpath/libnode.147.dylib;
• the copied executable cannot locate that dylib and exits before the verifier code;
• none of the Compute Fabric G1: stable local host identity + Host Capability Snapshot v1 #280 changed paths touch the toolchain-verifier implementation/test.

This is recorded as extra regression evidence, not normalized into a full-suite PASS.

Current hard blocker

The live M5 DevSpace server catalog includes git_commit, but this ChatGPT conversation's M5 callable projection does not expose that action. The live server/session still reports CURRENT/converged=true and client_projection=null.

The other callable dev namespace is a different server/state root and does not have this workspace loaded, so it cannot substitute without breaking provenance.

Therefore:

• no bare shell commit;
• no cross-server commit;
• no synthetic Candidate/Core provenance;
• no Candidate-ready claim yet.

James3014/devspace#240 has been reopened as KEEP_OPEN / SAME_CONTRACT_INCOMPLETENESS.

Current frontier:

ISSUE280_VERIFIED_DIRTY_PAYLOAD_AWAITING_SAME_M5_GIT_COMMIT_PROJECTION

Maximum claim: G1 source/test payload satisfies its required focused verifier set, but immutable Candidate formation and independent acceptance are not yet possible.

[James3014]

CONTRACT_DELTA — alternate-host repository recovery attempt authorized

Owner goal remains unchanged: complete Compute Fabric G1 so G2 can proceed.

The original M5 attempt remains historical and unresolved:

• workspace ws_1a29266dae
• Core session cms_73b3933c5d8345d9a1dd62fe594d3b52
• base 1f1ec9465dbb8edd0c67c91faee5d406878322ac
• dirty source effect only; no Candidate commit exists
• current M5 ChatGPT callable projection still lacks live-server git_commit

This delta does not rebind or impersonate that provenance.

A new repository-portable recovery attempt may start from fresh current devspace/main on another authorized DevSpace host, with:

• new workspace / Core session / operation / attempt identities;
• same Compute Fabric G1: stable local host identity + Host Capability Snapshot v1 #280 bounded product contract and allowed implementation surface;
• no reuse of the M5 Core actor/session;
• no external/runtime effect duplication;
• independent Candidate acceptance required;
• final persistent-host/runtime verification on the M5 canonical host remains required before G1 integration can unlock nexus-runtime fix(git): bind promotion to canonical runtime lineage #38.

The old M5 dirty worktree must remain untouched until separately reconciled; it is not evidence for the new Candidate.

Current fresh GitHub main at delta creation:
3ca5786ba9d2ad9446e1325d76e48a6424cf9cae

RECOVERY_ATTEMPT_2_AUTHORIZED_REPO_PORTABLE_IMPLEMENTATION_ONLY
AUTO_CHAIN=false.