zz_

app/engine/lane.ts

zzmq.dev@gmail.com/zz / app / engine / lane.ts @ b4dbd262 Download
Ladder Summary
  • file The module implements the core “lane” primitives that drive a lane’s lifecycle: **`proposeLane`** creates and persists a new `Lane` record, **`ask`** appends an ASK entry to a lane’s history, **`addRelatedLane`** records a child‑lane relationship, and **`answer`** records an ANSWER entry (with duplicate‑answer and RBAC checks) – all performed atomically through the backend resolved by `resolveBackend()`. No classes are exported; the only exported symbols are the four async functions listed above.
 // The Lane lifecycle: ASK/ANSWER/claim/merge-grant as real functions over
 // the existing .zz/ persistence (engine/store.ts) and Ladder storage
 // (engine/ladderNotes.ts), not just data types. Role-checking is deferred
 // to a later step (see the plan) -- this step is about getting the
 // protocol functions themselves working end to end. The actual work
 // queue (claiming, dependencies, the worker loop) lives in
 // engine/workqueue.ts, built on top of the ask()/answer() primitives
 // here.
 import { randomBytes } from "node:crypto";
 import { readLane, writeLane } from "./store.js";
 import { appendRepoChildren, writeLadder } from "./ladderNotes.js";
 import type { AnswerEntry, AskEntry, AskKind, Lane, LaneRef, LaneStatus, Trigger } from "./types.js";
 import type { Rung, RungKind } from "./ladder.js";
 import { REPO_RUNG_PATH } from "./ladder.js";
 
 function nowIso(): string {
  return new Date().toISOString();
 }
 
 // Random, not sequential: ids are minted independently by whoever
 // creates an Ask/Answer, with no shared counter to coordinate around --
 // a monotonic counter is exactly the kind of contended state that breaks
 // once there are multiple concurrent readers/writers of the same queue.
 function randomId(prefix: string): string {
  return `${prefix}-${randomBytes(5).toString("hex")}`;
 }
 
 export function proposeLane(
  stateDir: string,
  input: { id: string; repo: string; name: string; objective: string; scope: string[]; proposedBy: string; origin?: LaneRef | null; reason?: string; coordinators?: string[] },
 ): Lane {
  const trigger: Trigger = { kind: "manual", proposed_by: input.proposedBy, reason: input.reason };
  const lane: Lane = {
  id: input.id,
  repo: input.repo,
  origin: input.origin ?? null,
  name: input.name,
  objective: input.objective,
  status: "proposed",
  scope: input.scope,
  trigger,
  coordinators: input.coordinators ?? [input.proposedBy],
  history: [],
  related_lanes: [],
  };
  writeLane(stateDir, lane);
  return lane;
 }
 
 function requireLane(stateDir: string, laneId: string): Lane {
  const lane = readLane(stateDir, laneId);
  if (!lane) throw new Error(`no such lane: ${laneId}`);
  return lane;
 }
 
 export function ask(stateDir: string, laneId: string, input: { kind: AskKind; from: string; payload?: unknown; depends_on?: string[]; priority?: number }): AskEntry {
  const lane = requireLane(stateDir, laneId);
  const entry: AskEntry = {
  id: randomId("ask"),
  type: "ASK",
  kind: input.kind,
  from: input.from,
  payload: input.payload,
  depends_on: input.depends_on,
  priority: input.priority,
  at: nowIso(),
  };
  lane.history.push(entry);
  writeLane(stateDir, lane);
  return entry;
 }
 
 // Only kinds that describe *this lane's own* lifecycle drive a status
 // transition. Work-item kinds (ingest_repo, analyze_changeset, ...) and
 // cross-lane messages (merge_request lands in a *different* lane's
 // queue than the one whose work it's about) never do.
 const STATUS_ON_GRANT: Partial<Record<AskKind, LaneStatus>> = {
  claim_request: "claimed",
  review_request: "active",
 };
 
 export function answer(stateDir: string, laneId: string, theAsk: AskEntry, input: { from: string; action: AnswerEntry["action"]; payload?: unknown }): AnswerEntry {
  const lane = requireLane(stateDir, laneId);
  const entry: AnswerEntry = { id: randomId("answer"), type: "ANSWER", ask: theAsk.id, from: input.from, action: input.action, payload: input.payload, at: nowIso() };
  lane.history.push(entry);
  if (input.action === "grant") {
  const nextStatus = STATUS_ON_GRANT[theAsk.kind];
  if (nextStatus) lane.status = nextStatus;
  }
  writeLane(stateDir, lane);
  return entry;
 }
 
 // Which actor may act on (claim, or grant/deny/complete) an ask of a
 // given kind: "coordinator" means only someone in that lane's
 // `coordinators` list; "open" means anyone. A property of the kind, not
 // a central lock -- the query that reads this (engine/workqueue.ts's
 // claimableAsks) is what a real concurrent actor would run against a
 // shared queue.
 export const ASK_SCOPE: Record<AskKind, "coordinator" | "open"> = {
  claim_request: "coordinator",
  merge_request: "coordinator",
  review_request: "coordinator",
  change_request: "coordinator",
  coordinator_request: "coordinator",
  rung_update_request: "coordinator",
  ingest_repo: "open",
  analyze_changeset: "open",
  add_filechange: "open",
  summarize_changeset: "open",
+ work: "open",
 };
 
 /**
  * Writes a Rung (or several top-level Rungs) into the repo's Ladder.
  * The only place git notes actually get mutated -- called from the
  * `merge_request` handler when the repo Lane's queue processes one, not
  * by whoever built the Ladder. No longer gated on any Lane's `.status`:
  * in the queue model, access is controlled by who's allowed to claim a
  * `merge_request` ask (ASK_SCOPE above), not by this function.
  */
 export async function mergeLaneLadder(repoDir: string, stateDir: string, laneLadder: Rung | Rung[]): Promise<void> {
  const rungs = Array.isArray(laneLadder) ? laneLadder : [laneLadder];
  for (const rung of rungs) {
  await writeLadder(repoDir, stateDir, rung);
  }
  const asChildren = rungs.filter((r) => r.path !== REPO_RUNG_PATH);
  if (asChildren.length) {
  await appendRepoChildren(repoDir, stateDir, asChildren.map((r) => ({ path: r.path, kind: r.kind as RungKind })));
  }
 }