Skip to content

multi-project-sequencing.md

Latest commit

 

History

History
51 lines (37 loc) · 4.53 KB

multi-project-sequencing.md

File metadata and controls

51 lines (37 loc) · 4.53 KB
Raw

Multi-Project Sequencing and Dependency Analysis

← Docs index

Foundational layer

This note aligns sequencing across FN-3448, FN-3449, FN-3503, and FN-3182 using current contracts in docs and code.

Evidence highlights:

  • docs/shared-mesh-protocol.md defines strong writes, quorum/ack, fencing, and explicitly marks FN-3449 as part of the protocol implementation sequence (Section 14).
  • packages/core/src/central-db.ts defines projects(id, path UNIQUE, nodeId, settings) where id is canonical registry identity and path is a unique local filesystem location.
  • packages/core/src/central-core.ts generates RegisteredProject.id (proj_<uuid>), stores absolute path, and treats node assignment via assignProjectToNode() / unassignProjectFromNode() as separate from registration.
  • docs/multi-project.md already distinguishes runtime placement (projects.nodeId) from task-routing defaults (defaultNodeId).
  • packages/core/src/plugin-store.ts persists plugin rows in per-project .fusion/fusion.db today (project-root-scoped store).
  • FN-3182 spec moves plugin install metadata to central DB with per-project state keyed by project path; FN-3503 introduces project-per-node path mappings to avoid assuming identical absolute paths on every node.

Identity model

Current identity boundaries are not interchangeable:

  • RegisteredProject.id (central logical identity): stable registry key for cross-node/project orchestration.
  • projects.path (local absolute path): host-local location; unique in one registry DB, but not portable identity across nodes.
  • projects.nodeId (runtime placement): where a project runtime is hosted; not a task routing default and not a filesystem mapping key.
  • Project settings defaultNodeId (task dispatch default): separate from runtime placement (docs/multi-project.md).
  • Plugin scope today is project-local (PluginStore(rootDir)); FN-3182 proposes global install + project-scoped enablement, but its draft model still depends on path-based keys and therefore intersects FN-3503 identity work.

Implication: any multi-node plugin/project-state design that treats projects.path as cluster identity will conflict with FN-3503’s per-node path mapping direction.

Recommended sequencing

Recommended board edges (hard vs alignment):

  • Hard prerequisite: FN-3448 -> FN-3449 (already present; keep).
  • No dependency needed: FN-3449 does not need FN-3503 or FN-3182 to land its allocator contract.
  • Can proceed locally now, but needs follow-on alignment: FN-3182 can implement global install + per-project enablement for single-node/local multi-project flows now, but should preserve a migration seam for project identity keys once node-specific path mapping lands.
  • Recommended alignment edge: FN-3503 -> FN-3182 for full multi-node correctness, because FN-3503 supplies the missing canonical model for node-specific working directories that path-keyed plugin state otherwise bakes in.

Bridge-task recommendation (if board wants stricter decomposition):

  • Create a follow-up bridge task after FN-3503 to migrate any path-keyed project-scoped plugin rows to RegisteredProject.id (with node-aware resolution where needed), then have that bridge task feed final FN-3182 mesh-safe state semantics.

Comment recommendations to post:

  • On FN-3449: keep only the existing hard dependency on FN-3448; do not add FN-3503/FN-3182 dependencies.
  • On FN-3503: call out that this task is the identity substrate for any cross-node feature currently keying by local absolute path.
  • On FN-3182: recommend adding dependency on FN-3503 for cluster-safe identity, or explicitly scope first landing to local/single-node semantics with planned follow-up migration.

Risks of out-of-order execution

  • If FN-3182 lands full multi-node semantics before FN-3503, path-keyed per-project state can silently split/alias one logical project across nodes.
  • If implementers conflate projects.nodeId with defaultNodeId, runtime placement and task dispatch behavior may diverge in production (docs/multi-project.md explicitly separates them).
  • If teams treat projects.path as a durable cross-node identity instead of location metadata, later migration to per-node mappings becomes a data-rewrite project instead of a bounded compatibility migration.
  • If FN-3449 is delayed behind unrelated identity tasks, mesh write-coordination rollout loses its first strongly coordinated write primitive even though its contract is already anchored by FN-3448.

Task references: FN-3448, FN-3449, FN-3503, FN-3182.