@codeyam-editor/codeyam-editor 0.1.4 → 0.1.6

package/npm/fleet-pool.js

@@ -22,8 +22,11 @@
 //
 // On-disk shape (tolerant: a missing or malformed file is the empty pool):
 //   { "vms": { "<n>": { status, branch, freshAt, claimedAt } } }
-//     status:    "pool"      idle, claim-ready
-//                "assigned"  claimed by an operator, rebranded to `branch`
+//     status:    "pool"          idle, claim-ready (authenticated + push-ready)
+//                "pending-auth"   reachable + LB-wired but awaiting operator auth;
+//                                 counts toward the provisioning target (so the
+//                                 keeper converges) but is NOT claimable
+//                "assigned"       claimed by an operator, rebranded to `branch`
 //     branch:    the branch the VM is on (base branch while pooled)
 //     freshAt:   ISO timestamp of the last successful auth/health refresh —
 //                drives evict-before-claim of a member whose token lapsed
@@ -45,6 +48,20 @@ const POOL_STATE_FILE = process.env.POOL_STATE_FILE
 
 const POOL = 'pool';
 const ASSIGNED = 'assigned';
+// A VM that passed every readiness item EXCEPT provider auth (reachable,
+// on-branch, broker up, editor+preview 200, git-push-ready). Provisioning has
+// converged — the VM exists and is LB-wired — so it counts toward the refill
+// target and the keeper stops churning; but it is never claimable, so the claim
+// path still hands out only fully-authenticated VMs (the 2026-06-29 guarantee).
+const PENDING_AUTH = 'pending-auth';
+
+// Canonical status coercion: an unrecognized status is not a pool member.
+function coerceStatus(status) {
+  if (status === ASSIGNED) return ASSIGNED;
+  if (status === PENDING_AUTH) return PENDING_AUTH;
+  if (status === POOL) return POOL;
+  return null;
+}
 
 // ── Pure state helpers ──────────────────────────────────────────────────────
 
@@ -61,7 +78,7 @@ function normalizeState(raw) {
     const n = Number(key);
     if (!Number.isInteger(n) || n <= 0) continue;
     const e = vms[key] || {};
-    const status = e.status === ASSIGNED ? ASSIGNED : e.status === POOL ? POOL : null;
+    const status = coerceStatus(e.status);
     if (!status) continue;
     out.vms[n] = {
       status,
@@ -91,6 +108,13 @@ function assignedMembers(state) {
   return membersByStatus(state, ASSIGNED);
 }
 
+// VMs provisioned + LB-wired but awaiting operator auth. They count toward the
+// refill target (provisioning has converged) yet are excluded from poolMembers,
+// so selectForClaim never hands one out.
+function pendingAuthMembers(state) {
+  return membersByStatus(state, PENDING_AUTH);
+}
+
 // True when a pool entry's auth/health is older than `ttlMs` (its token may
 // have lapsed). An entry with no `freshAt` is treated as stale — "freshness
 // not proven" fails closed, mirroring fleet-ready's auth gate. Only meaningful
@@ -109,12 +133,16 @@ function staleMembers(state, nowMs, ttlMs) {
   return poolMembers(state).filter((n) => isStale(state.vms[n], nowMs, ttlMs));
 }
 
-// How many NEW pool VMs the keeper must provision to reach `target` idle
-// members. Assigned VMs do not count toward the pool — once claimed they're
-// gone from the warm set until released — so a claim naturally triggers a
-// refill. Never negative (an over-target pool is shrunk by policy, not here).
+// How many NEW VMs the keeper must provision to reach `target`. `have` counts
+// BOTH claim-ready pool members AND pending-auth members: provisioning has
+// converged once N reachable+wired VMs exist, regardless of auth, so the deficit
+// closes and the keeper stops churning (the 2026-07-09 endless-refill fix). Only
+// the provisioning denominator widens — poolMembers (claim eligibility) is
+// untouched, so a claim still selects only fully-authenticated VMs. Assigned VMs
+// do not count (claimed → gone from the warm set until released). Never negative
+// (an over-target pool is shrunk by policy, not here).
 function refillCount(state, target) {
-  const have = poolMembers(state).length;
+  const have = poolMembers(state).length + pendingAuthMembers(state).length;
   return Math.max(0, target - have);
 }
 
@@ -141,16 +169,18 @@ function selectForClaim(state, count, branch, nowIso) {
 }
 
 // Register (or overwrite) a VM in the pool state. The keeper calls this after
-// provisioning a fresh READY VM (status=pool) and the claim path can re-add an
-// assigned VM. `freshAt` defaults to now for a pool member so a just-verified
-// VM isn't immediately stale.
+// provisioning: status=pool for a fully-READY VM, status=pending-auth for one
+// that is reachable+wired but still awaiting operator auth; the claim path can
+// re-add an assigned VM. `freshAt` is stamped to now for a pool OR pending-auth
+// member (both were just verified live) so neither is immediately stale; an
+// unknown status coerces to pool.
 function applyAdd(state, n, status, branch, nowIso) {
   const next = normalizeState(state);
-  const st = status === ASSIGNED ? ASSIGNED : POOL;
+  const st = coerceStatus(status) || POOL;
   next.vms[n] = {
     status: st,
     branch: branch || null,
-    freshAt: st === POOL ? nowIso : (next.vms[n] && next.vms[n].freshAt) || null,
+    freshAt: st === ASSIGNED ? (next.vms[n] && next.vms[n].freshAt) || null : nowIso,
     claimedAt: st === ASSIGNED ? nowIso : null,
   };
   return next;
@@ -188,6 +218,18 @@ function applyMarkFresh(state, n, nowIso) {
   return next;
 }
 
+// Promote a pending-auth VM to a claim-ready pool member — the dashboard calls
+// this the instant an operator completes that VM's OAuth, so it becomes
+// claimable with NO re-provision. `freshAt` resets to now (it was just proven
+// authenticated). A no-op unless the VM is currently pending-auth, so it is safe
+// to call for any authenticated VM (an already-pooled or absent VM is untouched).
+function applyPromote(state, n, nowIso) {
+  const next = normalizeState(state);
+  if (!next.vms[n] || next.vms[n].status !== PENDING_AUTH) return next;
+  next.vms[n] = { ...next.vms[n], status: POOL, freshAt: nowIso, claimedAt: null };
+  return next;
+}
+
 // ── Atomic file layer ───────────────────────────────────────────────────────
 
 // Synchronous millisecond sleep without a busy CPU spin — used by withLock's
@@ -260,9 +302,11 @@ module.exports = {
   POOL_STATE_FILE,
   POOL,
   ASSIGNED,
+  PENDING_AUTH,
   normalizeState,
   poolMembers,
   assignedMembers,
+  pendingAuthMembers,
   isStale,
   staleMembers,
   refillCount,
@@ -271,6 +315,7 @@ module.exports = {
   applyRelease,
   applyEvict,
   applyMarkFresh,
+  applyPromote,
   withLock,
   readState,
   writeState,
@@ -312,6 +357,9 @@ function main(argv) {
     case 'assigned-members':
       process.stdout.write(`${assignedMembers(readState()).join(' ')}\n`);
       return 0;
+    case 'pending-auth-members':
+      process.stdout.write(`${pendingAuthMembers(readState()).join(' ')}\n`);
+      return 0;
     case 'refill-count': {
       const target = Number(flags.target);
       if (!Number.isInteger(target) || target < 0) {
@@ -357,8 +405,10 @@ function main(argv) {
         process.stderr.write('fleet-pool: add needs --vm <pos int>\n');
         return 2;
       }
-      const status = flags.status === ASSIGNED ? ASSIGNED : POOL;
-      withLock(() => writeState(applyAdd(readState(), vm, status, flags.branch, now)));
+      // applyAdd coerces the status (pool | pending-auth | assigned; unknown →
+      // pool), so pass the raw flag through — this is how the keeper adds a
+      // reachable-but-unauthed VM with `--status pending-auth`.
+      withLock(() => writeState(applyAdd(readState(), vm, flags.status, flags.branch, now)));
       return 0;
     }
     case 'release': {
@@ -388,9 +438,18 @@ function main(argv) {
       withLock(() => writeState(applyMarkFresh(readState(), vm, now)));
       return 0;
     }
+    case 'promote': {
+      const vm = Number(flags.vm);
+      if (!Number.isInteger(vm) || vm <= 0) {
+        process.stderr.write('fleet-pool: promote needs --vm <pos int>\n');
+        return 2;
+      }
+      withLock(() => writeState(applyPromote(readState(), vm, now)));
+      return 0;
+    }
     default:
       process.stderr.write(
-        'fleet-pool: usage: <list|pool-members|assigned-members|refill-count|stale|claim|add|release|evict|mark-fresh> [--flags]\n',
+        'fleet-pool: usage: <list|pool-members|assigned-members|pending-auth-members|refill-count|stale|claim|add|release|evict|mark-fresh|promote> [--flags]\n',
       );
       return 2;
   }

package/npm/fleet-prewarm.js

@@ -0,0 +1,241 @@
+'use strict';
+
+// npm/fleet-prewarm.js — pure verdicts for the fleet dashboard's concurrent
+// cold-add pre-warm (vm--concurrent-add-prewarm-branch-image).
+//
+// When several VMs are added at once on a branch whose prebuilt image is not yet
+// published, EVERY VM compiles the editor from source (~10 min each) in
+// parallel — none has finished compiling-and-publishing before its siblings
+// start, so the self-feeding fast path (publish_compiled_binary in
+// scripts/gcp-bootstrap.sh) never gets a chance to prime. The fix is to bring up
+// ONE "pacer" VM first, wait until it has published the branch binary (or
+// settled on a definite won't-publish), then release the rest so they pull it.
+//
+// This module holds the *decisions* — pace-or-fan-out, which tags constitute a
+// usable image, parsing the bootstrap's machine markers, and the push-token
+// diagnostic — so each case is unit-tested without a live VM or registry. The
+// I/O (the manifest probe, reading the add log, threading the held queue) lives
+// in the server / cloud.js shells that call these.
+
+// Machine-detectable markers gcp-bootstrap.sh emits into the cloud:up add log
+// (streamed to /tmp/dash-add-vm-<n>.log). They are stable contracts the
+// dashboard greps for — keep them in sync with scripts/gcp-bootstrap.sh.
+const MARKER_PUBLISHED = 'CY_BINARY_PUBLISHED'; // pacer published the branch binary; held adds can pull it
+const MARKER_PUBLISH_SKIPPED = 'CY_BINARY_PUBLISH_SKIPPED'; // pacer will NOT publish (no token / no branch / failure)
+const MARKER_PATH_PULL = 'CY_PROVISION_PATH pull'; // this VM pulled a prebuilt image (~2 min fast path)
+const MARKER_PATH_COMPILE = 'CY_PROVISION_PATH compile'; // this VM compiled from source (~10 min slow path)
+
+// Markers scripts/cloud-refresh-binary.sh emits into the between-session
+// refresh log (/tmp/dash-refresh-binary-vm-<n>.log, or the systemd journal when
+// the timer runs it unattended). Same stable-contract rule as the four above.
+const MARKER_REFRESHED = 'CY_BINARY_REFRESHED'; // pulled + swapped a newer published binary, container restarted
+const MARKER_REFRESH_CURRENT = 'CY_BINARY_CURRENT'; // already on the newest published binary; nothing to do
+const MARKER_REFRESH_DEFERRED = 'CY_BINARY_REFRESH_DEFERRED'; // newer binary exists but a session is live (or state unknown)
+const MARKER_REFRESH_DEGRADED = 'CY_DEGRADED binary-refresh'; // the refresh could NOT complete — this VM may be running stale
+
+// Mirror scripts/gcp-bootstrap.sh's BRANCH_SLUG: '/' → '-', lowercased, capped
+// at 128 chars. The dashboard and the VM MUST agree on the slug or the probe
+// checks different tags than the bootstrap pulls. Empty / missing branch → the
+// universal "main" slug, matching the bootstrap's detached-HEAD fallback.
+function branchSlug(branch) {
+  if (!branch || typeof branch !== 'string') return 'main';
+  const slug = branch.replace(/\//g, '-').toLowerCase().slice(0, 128);
+  return slug || 'main';
+}
+
+// The tag chain that constitutes a "usable" prebuilt editor image, in the same
+// precedence the dev bootstrap pulls (build_editor_image in gcp-bootstrap.sh):
+//   1. cloud-smoke:<slug>-latest   — the branch base image
+//   2. cloud-smoke:main-latest     — the universal CI fallback (skipped when
+//                                    the branch already IS main, no duplicate)
+//   3. binary:<slug>-latest        — the branch binary overlay
+// If a manifest HEAD on ANY of these succeeds, a cold add can pull instead of
+// compiling, so no pacer is needed. Registry defaults to the same
+// CODEYAM_REGISTRY the bootstrap reads.
+function usableImageTags({ registry, branch } = {}) {
+  const reg = registry || 'ghcr.io/codeyam-ai';
+  const slug = branchSlug(branch);
+  const tags = [`${reg}/codeyam-editor-cloud-smoke:${slug}-latest`];
+  if (slug !== 'main') tags.push(`${reg}/codeyam-editor-cloud-smoke:main-latest`);
+  tags.push(`${reg}/codeyam-editor-binary:${slug}-latest`);
+  return tags;
+}
+
+// The core verdict: should a cold add pace one VM to compile+publish first?
+//
+//   count           how many VMs the operator asked to add
+//   hasUsableImage  the probe result — true (image present), false (definitely
+//                   absent), or null (couldn't determine: no token, probe error)
+//   hasPushToken    a write:packages token is present, so the pacer CAN publish
+//
+// Pace ONLY when it strictly pays AND can work:
+//   - count >= 1           — a batch (k>1) serializes ONE ahead so the rest pull;
+//                            a single cold add (k==1) still paces so it PUBLISHES
+//                            the branch image, making every FUTURE add (single or
+//                            batch) pull instead of source-building. Gating the
+//                            publish behind k>1 was a bug: adding VMs one at a time
+//                            bypassed the pacer entirely, so no image was ever
+//                            produced and every single add recompiled.
+//   - hasUsableImage !== true — a usable image lets all N pull concurrently, so
+//                               only pace when one is NOT known to exist. Both
+//                               `false` (known-absent) AND `null` (undetermined)
+//                               pace: publishing is cheap + idempotent, and pacing
+//                               is the ONLY path that bootstraps self-feeding.
+//                               Fanning out on `null` is exactly what permanently
+//                               wedges a docker-less operator host whose probe can
+//                               never confirm absence (see
+//                               npm/cloud.js::probeUsableEditorImage) — republishing
+//                               an image that already existed is the harmless worst
+//                               case.
+//   - hasPushToken         — without it the pacer can't publish, so pacing would
+//                            just serialize N source compiles for no gain
+// Fan out immediately only when a usable image is KNOWN to exist, or there is no
+// push token (today's behavior for those two cases, strictly additive).
+function decideBatchPrewarm({ count, hasUsableImage, hasPushToken } = {}) {
+  const k = Math.round(Number(count) || 0);
+  if (k < 1) return { pace: false, reason: 'no VMs requested' };
+  if (hasUsableImage === true)
+    return { pace: false, reason: 'usable prebuilt image exists — all pull concurrently' };
+  if (!hasPushToken)
+    return { pace: false, reason: 'no push token — pacer could not publish, fan out' };
+  // hasUsableImage is `false` (known-absent) or `null` (undetermined); with a push
+  // token, pace either way to bootstrap self-feeding.
+  const basis = hasUsableImage === false
+    ? 'branch image absent'
+    : 'image presence undetermined — publishing to bootstrap self-feeding';
+  return {
+    pace: true,
+    reason: k > 1
+      ? `pacing 1 of ${k} — ${basis}, will publish for the rest`
+      : `single cold add — ${basis}, will compile and publish so future adds pull`,
+  };
+}
+
+// Has the pacer's add log settled to a definite publish outcome the held batch
+// can act on? Returns 'published' (binary is now pullable — release and pull),
+// 'skipped' (pacer will NOT publish — release; they recompile, today's
+// behavior), or null (still in flight — keep waiting). A SKIPPED that is later
+// followed by a PUBLISHED still reports published (the success wins), so marker
+// ordering can't strand the batch on a transient earlier skip.
+function detectPublishSettled(logText) {
+  if (!logText || typeof logText !== 'string') return null;
+  if (logText.includes(MARKER_PUBLISHED)) return 'published';
+  if (logText.includes(MARKER_PUBLISH_SKIPPED)) return 'skipped';
+  return null;
+}
+
+// The pure release decision for the pre-warm hold (startPrewarmWatch's per-tick
+// verdict): given the pacer's current signals, should the held batch be released
+// now, and why? Returns a human reason string to release, or null to keep
+// waiting. Releases on the FIRST of: a settled publish marker, the pacer job
+// terminating without one, or the bounded timeout — so a publish failure or a
+// stuck pacer can never strand the batch.
+//
+//   settled     detectPublishSettled() result: 'published' | 'skipped' | null
+//   pacerJob    the pacer add job record ({ state, ... }) or null/undefined
+//   elapsedMs   ms since the watch started
+//   timeoutMs   the bounded fallback after which the batch releases regardless
+function prewarmReleaseDecision({ settled, pacerJob, elapsedMs, timeoutMs } = {}) {
+  if (settled) return `pacer ${settled}`;
+  const st = pacerJob && pacerJob.state;
+  if (st === 'done' || st === 'error') return `pacer ${st}`;
+  if (Number(elapsedMs) > Number(timeoutMs)) return 'timeout';
+  return null;
+}
+
+// Which provision path did a VM take, parsed from its add log's path marker?
+// Returns 'pull' (~2 min prebuilt pull), 'compile' (~10 min source compile), or
+// null (not yet determined). The LAST marker wins — a VM that tries a pull,
+// misses, then falls back to a compile correctly reads 'compile'.
+function provisionPath(logText) {
+  if (!logText || typeof logText !== 'string') return null;
+  const pull = logText.lastIndexOf(MARKER_PATH_PULL);
+  const compile = logText.lastIndexOf(MARKER_PATH_COMPILE);
+  if (pull < 0 && compile < 0) return null;
+  return compile > pull ? 'compile' : 'pull';
+}
+
+// Operator-facing one-liner for a provision path, for the add card sub-status.
+// null path → null (render nothing).
+function provisionPathLabel(path) {
+  if (path === 'pull') return 'pulling prebuilt image (~2 min)';
+  if (path === 'compile') return 'compiling from source (~10 min)';
+  return null;
+}
+
+// The push-token diagnostic surfaced on the dashboard. Without a write:packages
+// token the self-feeding publish is silently off, so EVERY cold add recompiles
+// (~10 min) and the pacer can't help either — a state the operator must see, not
+// discover from a buried per-VM log line.
+function pushTokenDiagnostic({ hasPushToken } = {}) {
+  if (hasPushToken) return { warn: false, message: null };
+  return {
+    warn: true,
+    message:
+      'Self-feeding disabled: no CODEYAM_GHCR_PUSH_TOKEN (write:packages). ' +
+      'Cold adds will always recompile the editor from source (~10 min each) ' +
+      'and concurrent batches cannot pre-warm. Install a write-scoped token and ' +
+      'reinstall the fleet agents to enable the fast path.',
+  };
+}
+
+// What did the last between-session binary refresh do? Parsed from the refresh
+// log for the VM card, so an operator can tell "up to date" from "could not
+// update" without opening a log.
+//
+// Returns 'refreshed' | 'current' | 'deferred' | 'degraded' | null (no refresh
+// has reported yet).
+//
+// The LAST marker wins, for the same reason provisionPath() takes the last one:
+// a tick that defers and a later tick that refreshes must read as refreshed,
+// not stay stuck on the older verdict. Ordering — not precedence between marker
+// kinds — is what makes this correct across repeated timer runs.
+//
+// `degraded` is deliberately a distinct state from `deferred`. Deferring is the
+// mechanism working as designed (a session is live, so we wait). Degraded means
+// the VM wanted a newer binary and could NOT get one — the silent-staleness
+// case this whole mechanism exists to make visible, and the only one that
+// warrants an operator's attention.
+function binaryRefreshState(logText) {
+  if (!logText || typeof logText !== 'string') return null;
+  const at = (marker) => logText.lastIndexOf(marker);
+  const candidates = [
+    ['refreshed', at(MARKER_REFRESHED)],
+    ['current', at(MARKER_REFRESH_CURRENT)],
+    ['deferred', at(MARKER_REFRESH_DEFERRED)],
+    ['degraded', at(MARKER_REFRESH_DEGRADED)],
+  ].filter(([, idx]) => idx >= 0);
+  if (!candidates.length) return null;
+  return candidates.reduce((best, cur) => (cur[1] > best[1] ? cur : best))[0];
+}
+
+// Operator-facing one-liner for a refresh state, for the VM card. null state →
+// null (render nothing — a VM that has never run a refresh is not a problem).
+function binaryRefreshLabel(state) {
+  if (state === 'refreshed') return 'editor binary refreshed to the newest published build';
+  if (state === 'current') return 'editor binary up to date';
+  if (state === 'deferred') return 'newer editor binary available — waiting for the session to end';
+  if (state === 'degraded') return 'could NOT refresh the editor binary — may be running stale';
+  return null;
+}
+
+module.exports = {
+  MARKER_PUBLISHED,
+  MARKER_PUBLISH_SKIPPED,
+  MARKER_PATH_PULL,
+  MARKER_PATH_COMPILE,
+  MARKER_REFRESHED,
+  MARKER_REFRESH_CURRENT,
+  MARKER_REFRESH_DEFERRED,
+  MARKER_REFRESH_DEGRADED,
+  binaryRefreshState,
+  binaryRefreshLabel,
+  branchSlug,
+  usableImageTags,
+  decideBatchPrewarm,
+  detectPublishSettled,
+  prewarmReleaseDecision,
+  provisionPath,
+  provisionPathLabel,
+  pushTokenDiagnostic,
+};

package/npm/fleet-project-drift.js

@@ -0,0 +1,58 @@
+'use strict';
+
+// npm/fleet-project-drift.js — pure classifier for the fleet dashboard's
+// "project-dir-drift" surface: does a VM's LIVE project identity conflict with
+// the identity the operator asked for at Add time?
+//
+// The drift surface exists to catch a genuine misprovision — a VM whose
+// /workspace checked out the WRONG repo, so its live project name no longer
+// matches the expected one. But a brand-new GREENFIELD project (added with
+// --new-project / newProjectName, no clientRepo) has no origin remote and, on a
+// cloud VM, is always bind-mounted at /workspace. Before the editor seeds its
+// projectTitle, the live identity falls back to the bare mount basename
+// "workspace", which never equals the expected newProjectName — a PERMANENT
+// FALSE drift that made every healthy greenfield add read amber and then get
+// misclassified as "Add failed". This module suppresses drift for exactly that
+// un-onboarded greenfield shape while leaving every true-positive intact.
+//
+// Pure like fleet-add-failure.js: server.js is the thin I/O shell that gathers
+// the poll state and renders the returned reasons; the decision is unit-tested
+// here without a live VM.
+
+// The bare basename of the cloud-VM bind mount. Every fleet VM mounts the
+// client project at /workspace (see server.js's in-container gather and the
+// `-w /workspace` exec target), so an un-onboarded greenfield project with no
+// origin resolves its live name to this literal string until the editor seeds a
+// real projectTitle.
+const MOUNT_BASENAME = 'workspace';
+
+// Decide the project-dir-drift reasons for one VM.
+//
+//   expectedName   the identity the operator asked for: repoBasename(clientRepo)
+//                  for a clone, else newProjectName for greenfield, else null
+//   liveName       the VM's live clientProject.name (null when unreachable)
+//   liveRepo       the VM's live clientProject.repo — null for a project with no
+//                  origin remote (always the case for a fresh greenfield add)
+//   hasClientRepo  whether the Add was configured with a clientRepo (a clone);
+//                  false for a --new-project greenfield add
+//
+// Returns { drifted, reasons }. `reasons` is [] when not drifted so the caller
+// can spread it into the card's reason list unconditionally.
+function classifyProjectDrift({ expectedName, liveName, liveRepo, hasClientRepo } = {}) {
+  // Un-onboarded greenfield: no configured clientRepo, no live origin remote,
+  // and the live name is still the bare mount basename. This is a healthy fresh
+  // project that simply has not been wired to a remote yet — never real drift.
+  // Note the live-origin check: once a greenfield project DOES gain an origin
+  // whose basename conflicts with expected, `liveRepo` is non-null and this
+  // suppression no longer applies, so a genuine later misprovision still drifts.
+  const greenfieldUnonboarded =
+    !hasClientRepo && !liveRepo && liveName === MOUNT_BASENAME;
+  const drifted =
+    !greenfieldUnonboarded && !!(expectedName && liveName && expectedName !== liveName);
+  const reasons = drifted
+    ? [`project-dir-drift (expected: ${expectedName}, running: ${liveName})`]
+    : [];
+  return { drifted, reasons };
+}
+
+module.exports = { classifyProjectDrift, MOUNT_BASENAME };