@teamscala/service-boot 0.23.522 → 0.23.524

package/src/build-client-assets.ts

@@ -1,35 +1,6 @@
 /**
- * @system server-handlers
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Builds the per-service client bundle and stylesheet into `dist/client/`
- * at UI-service boot time. Outputs are content-hashed so deployments
- * naturally cache-bust:
- *
- *   src/entry-client.ts  ──bun build──>  dist/client/hydrate-<hash>.js
- *   src/app.css          ──tailwindcss──>  dist/client/styles-<hash>.css
- *   (and)                                  dist/client/asset-manifest.json
- *
- * The HTML template references `{{stylesPath}}` / `{{hydratePath}}` —
- * read-html-template.ts substitutes from the manifest at template-read
- * time. Bytes-level changes → new hash → new URL → browser refetch.
- * Without this, `cache-control: immutable` on a fixed filename means
- * returning visitors keep their stale copy forever.
- *
- * This module is the ORCHESTRATION unit: host-wide lock → parallel
- * hydrate/CSS builds → manifest write (or failure tombstone). The
- * build runs on EVERY boot: the content-fingerprint skip cache and its
- * closure-walking hashers (input-fingerprint.ts, input-hashing.ts) are
- * deleted. A skip is the only path that can serve a stale bundle, and
- * it has done so twice (the mtime skip that baked stale bundles until
- * the fingerprint replaced it, 2026-06-14) — no skip is the one shape
- * that cannot skip wrongly, at the cost of a bounded per-boot build
- * serialised by the host-wide lock below. The individual concerns live
- * as siblings under ./build-client-assets/
- * (source-candidates, manifest, hashed-output, hydrate-bundle,
- * sourcemaps-upload, styles-build, build-lock)
- * — split when the parent held them all at 962 lines.
  */
 
 	// Each build is wrapped in its own catch so a JS bundle failure (e.g. transient cross-package export drift) doesn't take down the service

package/src/capability-slug.ts

@@ -1,40 +1,6 @@
 /**
- * @system ui-service-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Deployable slug -> capability slug.
- *
- * A DEPLOYABLE is named `<capability>-<language>-<tier>`
- * (`deployables-carry-language-and-tier`, as amended by the operator ruling of
- * 2026-09-08: "so actually the apps are ts, not bun" — the language segment
- * spells the LANGUAGE, so Bun-launched services are `ts`): `scala-projects-ts-dev`
- * and `scala-projects-ts-prod` are two DEPLOYMENTS of one APPLICATION. The
- * ecosystem generator derives that name per lane, so one service arrives here
- * under a DIFFERENT identity in each lane.
- *
- * A `page_route` row describes the APPLICATION url space, which is the same
- * in both lanes, so it carries the CAPABILITY name and there is exactly one
- * row per route rather than one per lane. Joining the two by raw string
- * equality therefore matches at most one lane, and does so SILENTLY:
- * measured 2026-09-11, 8 of 10 dev UI services registered ZERO page routes
- * and served 404 on every path -- including `/sign-in` -- while booting
- * clean and reporting healthy, because the dev lane ran as
- * `scala-projects-bun-dev` while every page_route row said `scala-projects`.
- *
- * Both sides normalize through this one function, so the join is
- * tier-agnostic by construction and a row may name either form.
- *
- * The suffix grammar is a CLOSED SET defined by doctrine and emitted by the
- * generator, so this is a parse of a documented contract rather than a
- * pattern heuristic. A slug that does not end in one is already a capability
- * name and is returned unchanged.
- *
- * `bun` REMAINS IN THE SET AS RETIRED SPELLING TOLERANCE, mirroring the
- * generator side (`ecosystem/deployable_identity.rs capability_of` strips
- * `-ts`, `-bun` and `-rust`): the fleet was renamed under `-bun` and rows or
- * supervised names still carrying it must converge to the same capability
- * rather than fail the join during the migration window.
  */
 
 /** Language segment of a deployable name. `bun` is the retired spelling. */

package/src/compose-page-title.ts

@@ -1,30 +1,6 @@
 /**
- * @system ui-service-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The single canonical page-title composer. Every SSR page handler routes
- * through this (portal/region-shell, public shell, single-page resource). A
- * page title is DERIVED from data that already exists — the website name +
- * the page/entity name — with `builda_pages.meta_title` as an explicit
- * per-page OVERRIDE only, never the primary source.
- *
- * Mirrors the brand-is-org-owned-full-scheme precedent: a value that should
- * be DERIVED was instead hand-set per row, and when unset it silently fell
- * back to something wrong. For themes the wrong fallback was the generic
- * light palette; for titles it was the bare org name — the `default`
- * page_meta_template `titleTemplate: "{org.name}"` produced "GBG Indo" with
- * no site or page context, and per-row `meta_title` carried stale product
- * literals like "Dashboard | scala Hub". The fix is identical in shape:
- * derive by default, override explicitly.
- *
- * Canonical format: `<website.name>: <subject>` (subject = entity title or
- * page name), site-first so a browser tab reads the surface then the page.
- * A resource surface (forms/quiz/gpt) may supply a curated `templateTitle`
- * (e.g. "{agent.name} — {org.name}"); it wins over the default derivation
- * but NOT over an explicit per-page override. The composer NEVER returns a
- * bare org name — that is the regression this closes, and the
- * `page-title-not-bare-org` guard backstops it at the template layer.
  */
 
 export interface TitleContext {

package/src/content-gate/access.ts

@@ -1,14 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The content-gate ACCESS endpoint mounter. One generic POST handler for every
- * gate: a plain <form> posts {<recordIdField>, email}; on a match against the
- * resource's authorized set it sets the signed access cookie and redirects back,
- * so the page loader's gate then releases the content. No bespoke endpoint per
- * type — each gate is one AccessConfig. Mounted BEFORE the auth gate so it is
- * publicly reachable.
  */
 
 import type { Hono } from "hono";

package/src/content-gate/catalog.ts

@@ -1,29 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * THE CATALOG OF GATED CONTENT TYPES — the one place a gate is registered.
- *
- * The gate ENGINE (gate.ts) and the access MOUNTER (access.ts) were already
- * generic and config-driven, but the SEQUENCE was not: `register-registry-page-
- * route.ts` named proposalGateConfig + agreementGateConfig + gptGateConfig in a
- * hand-written array, and `two-phase-boot.ts` named the same three AccessConfigs
- * in a second hand-written array. Two lists, one fact, and adding a fourth gated
- * resource meant editing both — the same drift as the assistant, one layer down
- * (`information-exists-in-one-location`).
- *
- * Now both call sites iterate THIS. A gate is registered once, as a pair, and
- * the SSR gate and its public access endpoint cannot disagree about which gates
- * exist — the shape doctrine asks for when behaviour genuinely is code:
- * `business-logic-is-rows-plus-executors`, "extend the executor catalog".
- *
- * WHY A CATALOG AND NOT A REGISTRY ROW. A gate is not data — `verifyToken`,
- * `resolveAuthorizedEmails` and the withholding rules are executable behaviour,
- * which the rule places in a typed executor, never in a row. What belongs in a
- * row is the SELECTION: which gate governs a given page. That is a `page_route`
- * field, and a row can only select from a catalog, so this file is the thing it
- * will select from — not a step on the way to it.
  */
 
 /**

package/src/content-gate/config-types.ts

@@ -1,12 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The config contracts that PROGRAM a content gate. Each gated content type
- * (agreement, proposal, …) is one ContentGateConfig + one AccessConfig — no
- * bespoke gate functions per type; the engine (gate.ts) and the access mounter
- * (access.ts) are the single shared primitive driven by these.
  */
 
 type Resolved = Record<string, unknown>;

package/src/content-gate/gate-entry-clears.ts

@@ -1,24 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * REQUEST-SCOPED channel for gate-entry marker clears. A gate that declares an
- * entry marker (config.entryCookieName) consumes it on the render that the
- * access endpoint's own redirect produces; that render's response must clear
- * the marker, or the next load (a refresh) would still carry it and skip the
- * gate. The gate writes the name here; bindPageHandler — which owns the page
- * Response — drains it into Set-Cookie, so the marker lives exactly one view.
- *
- * THE CLEARS COME BACK AS THE CALL'S RETURN VALUE, never from a post-hoc
- * read: the store only exists inside the run() scope, so a reader called after
- * the awaited call has already left it and would see an empty list — which is
- * exactly how the first version of this file shipped a marker that was never
- * cleared (measured live 2026-09-14: the cookie survived the render).
- *
- * AsyncLocalStorage rather than a module-level map: request-scoped by
- * construction, no accumulated process state that a restart would silently
- * reset (in-memory-state-is-not-durable).
  */
 import { AsyncLocalStorage } from "node:async_hooks";
 

package/src/content-gate/gate.ts

@@ -1,13 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The content-gate ENGINE. Runs in the page loader after the resource graph
- * resolves, BEFORE SSR. Orchestration only — the per-type behaviour (which
- * resource, who's authorized, what to seed, how to withhold) is supplied by a
- * ContentGateConfig, so agreements/proposals/future gates are configs, not new
- * functions. The single place that decides whether gated bytes reach the HTML.
  */
 
 /**

package/src/content-gate/parse-cookie.ts

@@ -1,10 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Parse a single cookie value out of a raw Cookie header — shared by the
- * content-gate engine and any gate config.
  */
 
 export function parseCookie(

package/src/content-gate/token.ts

@@ -1,28 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The single signed, short-lived access token for EVERY content gate (agreement,
- * proposal, and any future gated content). A gate withholds page content
- * server-side until the request carries a valid token for that resource; this is
- * the only thing that releases the content into the SSR, so without it a gated
- * page is never readable/scrapable by a link holder.
- *
- * HMAC-SHA256 (Bun-native) over {c:cookieName, r:resourceId, e:email, x:exp},
- * plus the optional captured identity a lead-capture gate carries (n:name,
- * p:phone) so a returning visitor is fully known at SSR with NO client storage.
- * `cookieName` is bound INTO the payload so a token minted for one gate
- * (e.g. ag_token) can never satisfy another gate's check (e.g. prop_token).
- *
- * Secret resolver, in preference order: AUTH_SECRET → ENCRYPTION_KEY →
- * the tenant DB address via @teamscala/db's named-need resolver (first one
- * ≥16 chars). A gate signs AND verifies inside one
- * service, so it only needs a stable per-deployment secret; the fallback keeps a
- * gate working on a service that was never given AUTH_SECRET (e.g. the former
- * public-only proposals viewer) instead of failing closed and locking out every
- * authorized viewer. Any service that has AUTH_SECRET transparently prefers it.
- * Fail-closed: no usable secret yields null (no token, no access).
  */
 
 import type { GateSegmentation } from "./config-types.ts";

package/src/content-page-floor.ts

@@ -1,23 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Pure decision: does a CONTENT route (no resource_type) whose loader resolved
- * a `page` body source warrant the branded not-found floor? Extracted from
- * register-registry-page-route so the rule is unit-testable independent of the
- * Hono/DB/graph machinery that wraps it (the fix's correctness does not depend
- * on the publish — verify-before-done).
- *
- * Three outcomes:
- *   - no page row (deleted/unmatched path, e.g. /roadmap) → dead-link 404 floor
- *   - page row exists but zero content blocks → empty-page 200 floor
- *   - otherwise → null (render normally)
- *
- * The "Vision Toolbar" leak this closes: a content catchall synthesized an empty
- * page for an unmatched path and served a cacheable 200; resource-not-found-is-
- * the-root-floor only fired for resource_type routes, so dead content links fell
- * through. See resource-not-found.ts for the floor + operator ruling 2026-07-21.
  */
 import { PrimaryResourceMissingError } from "./resource-not-found.ts";
 

package/src/csrf-protection.ts

@@ -1,33 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * csrf-protection.ts — platform CSRF middleware (`security-csrf-protection`).
- *
- * Hono's csrf() with a DERIVED trusted-origin set, never a hand-authored
- * allowlist: every trusted origin comes from ONE source per
- * `offered-is-derived` —
- *   - the managed base domain (registry portal-domains) covers the platform's
- *     own `*.scala.business` origins, INCLUDING the cross-service form POST
- *     redirect chains CSP form-action allowlists (proposals → sign etc.), so
- *     the CSRF origin set and the CSP form-action set cannot disagree about
- *     what "one of ours" means;
- *   - customer custom domains resolve through `isTrustedAuthOrigin`
- *     (builda_websites lookup) — the SAME lookup better-auth's trustedOrigins
- *     uses in @teamscala/auth, so a new custom domain is trusted everywhere at
- *     once or nowhere.
- *
- * hono csrf() arms only on form-element content types (urlencoded, multipart,
- * text/plain) — browsers cannot produce a cross-site application/json request
- * from a form, so the JSON API surface (ORPC) is protected by cookie
- * SameSite=Lax + this middleware's text/plain coverage.
- *
- * Custom-domain lookups are cached per-hostname with a TTL: a POSITIVE result
- * is cached for the full TTL (a domain that stopped being ours keeps working
- * for at most the TTL), a NEGATIVE result for a short window (a brand-new
- * custom domain becomes trusted within seconds). The cache is a request
- * accelerator over a DB fact, never the source of truth.
  */
 
 import { getManagedBaseDomain } from "@teamscala/auth/auth-env-resolution";

package/src/error-page-logo.ts

@@ -1,29 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The error/holding page's brand logo: resolve the host org's dark-theme
- * wordmark from its install row and inline it as a data URI. Split from
- * resource-not-found.ts under single-purpose-file (the builder consumes a
- * logoUrl argument; only these resolvers touch storage and the registry).
- *
- * The host org's LOGO (wordmark) for the dark error page — the favicon is a
- * tab glyph, the wrong asset at page scale (operator-observed: a lone "h"
- * where the launcha wordmark belonged). Resolution: the service's own
- * install row names its owner (brand_org); the org's dark-theme logo (a
- * light-coloured mark, correct on the dark page) is preferred, light-theme
- * second. Every step skew-tolerant: any miss → null → the builder renders a
- * logo-less dark page.
- *
- * Returns the logo as an INLINE data URI (not a `/api/assets/` proxy URL) so
- * the branded holding/error page ships the logo IN the initial HTML bytes —
- * no second fetch, no post-paint pop-in, no dependency on the asset proxy the
- * degraded service is failing to serve (incident 2026-07-27: the logo on a
- * DEGRADED render-layer holding page appeared after the page painted). The
- * logo sibling of icons-render-ssr-inline. Size-capped: a pathological
- * (>MAX_INLINE_LOGO_BYTES) logo falls back to null rather than bloating the
- * HTML; the page renders logo-less, never broken.
  */
 
 import { getClient } from "@teamscala/object-storage/create/client/get-client";

package/src/expand-roster.ts

@@ -1,21 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Server-side roster expansion — the executor that handles "render N of block X
- * per data row" so the page never needs a domain-specific panel/list block. A
- * block authored with `props.dataRepeat: "parties"` is a TEMPLATE; before SSR
- * this clones it once per roster item into its parent slot (top-level content or
- * any Container's `content` slot), then drops the marker. Each clone:
- *   - sets `role` + `dataKey` to the item's key, so a prop-driven block (the
- *     SignatureField cell) finds its own party with no per-clone wiring;
- *   - substitutes `{{name}}` / `{{role}}` / `{{company}}` / `{{date}}` /
- *     `{{status}}` placeholders in any string prop (so a recipient row is plain
- *     `Container` + `Text` primitives — the copy lives on the page, not here).
- *     `{{status}}` resolves from the template's own `signedLabel` /
- *     `awaitingLabel` props (DB-driven copy), never hardcoded.
- * Generic over any roster; the agreement page passes its parties.
  */
 
 export interface RosterItem {

package/src/gate-ttls.ts

@@ -1,18 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Cached readers for the content-gate access-token TTL config rows
- * (agreement-gate / proposal-gate / gpt-gate / quiz-gate). initGateTtls() runs once at boot
- * (two-phase-boot, before the gates mount) to populate the cache from the
- * registry rows; the sync getters (agTtlMs/propTtlMs/gptTtlMs) return the
- * cached value — or the former hardcoded default before init / on row-miss — so
- * the sync AccessConfig.ttlMs fields + sync hono magic-link handlers read them
- * without async. Replaces the per-file AG_TTL_MS / PROP_TTL_MS / GPT_TTL_MS
- * constants (config-constants: the registry row is the source, dedup'd across
- * each gate + its attach-* magic counterpart so token TTL and cookie maxAge
- * never drift).
  */
 import { loadRegistryConfig } from "@teamscala/db/registry/load-config";
 import * as v from "valibot";

package/src/gpt-gate.ts

@@ -1,24 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The PUBLIC GPT identity gate, expressed as config for the content-gate
- * primitive (content-gate/). Unlike proposals/agreements this is NOT access
- * control — every email is a valid visitor (lead capture). Its whole job is to
- * make a returning visitor's identity known AT SSR so the GPT body renders the
- * real conversation on first paint instead of server-rendering the capture gate
- * and then swapping to the chat after hydration (the ssr-then-live-handoff +
- * "know the visitor at SSR first paint" violation: building-applications).
- *
- * Flow: the capture form POSTs {gptId, email} to /api/gpt-access (openCapture →
- * any email matches); the access endpoint sets a signed `gpt_token` cookie. On
- * the next request runContentGate verifies that cookie for this agent and seeds
- * resolved.initialVisitor — which the GPT body serverLoader (ssrGptSession) then
- * uses to SSR-restore the conversation, and GptBodyBlock uses to skip the gate.
- * onUnauthorized is a no-op: an un-gated (first-time) visitor sees the capture
- * form the block renders itself when no visitor is known — that is correct, not
- * a flash (they ARE anonymous), so there is nothing to withhold.
  */
 
 import type { AccessConfig, ContentGateConfig } from "./content-gate/config-types.ts";

package/src/hono-error-handler.ts

@@ -1,21 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * The single app.onError factory for every Hono app (UI + backend). Two error
- * classes, deliberately separate:
- *  - HTTPException: a DELIBERATE status-bearing throw (e.g. hono bodyLimit's
- *    413). Preserve its status + message verbatim — buildErrorReport only knows
- *    500/503 and would erase a deliberate 413/401/etc.
- *  - anything else: an UNEXPECTED error → buildErrorReport (errorId correlation,
- *    transient-vs-bug classification, 503 + Retry-After when retryable, else 500).
- *
- * Resolves the apparent tension between `hono-global-error-handler` (HTTPException
- * → status + JSON) and `error-responses-via-error-report` (every error response
- * via buildErrorReport): the latter governs UNEXPECTED errors; HTTPException is
- * the documented deliberate-status carve-out. The handler is a consumer of
- * buildErrorReport, never a second classifier for the unexpected branch.
  */
 
 import { getAppLogger } from "@teamscala/logger/app-loggers";

package/src/install-harness.ts

@@ -1,17 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Install harness — sandbox-mounts each declared package and captures
- * registry.require() calls via AsyncLocalStorage. Validates all required
- * rows exist before returning. Throws HarnessInstallError with full
- * context on failure. Per Constitution Rule 2 step 3.
- *
- * Marked: HarnessInstallError is the error class
- * validatePackageDependencies (might) throw — they form one canonical
- * "install harness validation" unit (the validator + the failure-mode
- * class it produces).
  */
 
 import {

package/src/install-logging.ts

@@ -1,20 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * One-call install of the entire logging pipeline. After installLogging()
- * runs, every error in the service — process-level, HTTP middleware, Hono
- * handlers, Puck blocks, even third-party packages calling console.* — is
- * captured by @teamscala/logger and flows to Sentry/GlitchTip (prod) or
- * loga (dev) with full context. Application code never imports the logger
- * or wraps anything in try/catch for telemetry purposes.
- *
- * Two phases, two files (single-purpose-file: the guard counts them as two
- * export groups in one file): installLogging (early bootstrap, hardcoded
- * defaults) lives here; applyLoggerConfig (late-stage, DB-driven) lives in
- * apply-logger-config.ts. The service boot pipeline calls them in sequence
- * with the same serviceSlug.
  */
 
 import { ManagedCache } from "@teamscala/cache/cache";

package/src/is-react-element-type.ts

@@ -1,16 +1,6 @@
 /**
- * @system ui-service-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Is a resolved module export something React can render?
- *
- * `typeof x === "function"` is NOT that question. memo(), forwardRef() and
- * lazy() all return OBJECTS carrying a `$$typeof` symbol, so a shape check on
- * `function` rejects three of React's own idioms as "not a component".
- * Measured 2026-09-01: scala-projects skipped PresenceAvatars for exactly this
- * reason — the block is `memo(function PresenceAvatarsBlock(...))` — and every
- * page rendering it came out blank with no error beyond one boot WARN.
  */
 
 export function isReactElementType(value: unknown): boolean {

package/src/load-page-manifest.ts

@@ -1,28 +1,6 @@
 /**
- * @system ui-service-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Loads the service's GENERATED `src/page-manifest.ts` — the codegen output of
- * the `page-manifest` transform, emitted from `block_schema` rows. That file is
- * the single artefact describing which Puck components this service renders.
- *
- * This REPLACES `discover-blocks.ts`, a hand-written runtime scan that queried
- * block_schema at boot and dynamic-imported each row. Deleting it is the point.
- * The scan was introduced to survive one dead row, and it bought that by moving
- * a build-time, deterministic, generated fact into a runtime path with four
- * independent ways to silently resolve nothing: a registry read that answers
- * with an empty array instead of failing, an install probe that reports "not
- * installed" for installed packages, a `node_modules` lookup relative to
- * `process.cwd()`, and a per-block try/catch that swallows each failure into a
- * string nobody reads when the boot dies first. Measured 2026-09-03: 91 active
- * block_schema rows, a generated manifest carrying 63 blocks sitting on disk,
- * and the scan loading ZERO — for hours, across every UI service.
- *
- * Generation is the platform's answer to exactly this (`one-generator-pattern`,
- * `business-logic-is-rows-plus-executors`): a bad row fails codegen loudly, at
- * build time, with the file in front of you. It cannot present as a service
- * that boots and renders nothing.
  */
 
 import { join } from "node:path";

package/src/load-service-install-row.ts

@@ -1,11 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Loads the service_install registry row for a given service slug.
- * Uses registry.require() per Constitution Rule 11.
- * Schema is owned by @teamscala/db-validation (Rule 7).
  */
 
 import { getCache } from "@teamscala/db/registry/loader/cache/get-cache";

package/src/module-not-found.ts

@@ -1,12 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Classifies a failed dynamic import as "this candidate is absent" vs a real
- * error, for the server_package mount candidate chain. Extracted from
- * mount-server-packages so the classification is testable: as a closure it
- * could not be exercised, and it shipped wrong.
  */
 
 /** `@scope/name/sub/path.ts` -> `@scope/name`; `name/sub` -> `name`. */

package/src/mount-orpc-router.ts

@@ -1,12 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Mounts the composed ORPC app router (generated Prisma CRUD + custom fn routers)
- * at /api/rpc/* over HTTP via @orpc/server/fetch's RPCHandler.
- * Uses getAppRouter() from @teamscala/orpc/app-router which merges generated
- * routers plus the row-composed fn namespace (orpc-bundle from api_route rows).
  */
 
 import { join } from "node:path";

package/src/mount-server-packages.ts

@@ -1,13 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Walks `service_install.server_packages[]`, dynamic-imports each, and calls
- * its `mount(ctx)` function. Server packages register handlers / boot hooks /
- * scheduled jobs / WS routes via the MountContext exposed in ctx; the
- * resulting MountRegistry is consumed by register-api-routes /
- * register-ws-routes / run-boot-hook-list / start-scheduled-jobs.
  */
 
 /**

package/src/mount.ts

@@ -1,9 +1,6 @@
 /**
- * @system server-boot
+ * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Server-package mount for opt-in service-boot watchdogs.
  */
 
 import type { MountContext } from "@teamscala/os/runtime-contracts/mount-context";

package/src/mutable-app-ref.ts

@@ -1,16 +1,6 @@
 /**
  * @system service-boot
  * @status handwritten
- * @edit edit directly
- *
- * Mutable app reference for two-phase boot. Allows swapping the Hono app
- * atomically after building the full app in the background. The initial app
- * is a minimal tool-only surface (ORPC, data routes) that starts serving
- * immediately; the full app (pages, hydration) is built off-to-the-side and
- * swapped in once complete.
- *
- * Thread-safety: Bun is single-threaded, so a simple module-level variable
- * is sufficient. Atomics are not needed.
  */
 
 import type { Hono } from "hono";

package/src/orpc-openapi-document.ts

@@ -1,18 +1,6 @@
 /**
  * @system service-boot
- * @status handwritten — none derivable: the title and the server URL are the MOUNT's facts (the slug it was handed, the host the request arrived on) and no row carries either — searched the portal's package-manifest rows (scala-portal, scala-portal-ts-dev, portal-ui, portal-shell) for a public base URL and the service_env rows for a configured origin; none carries one, so the reachable address can only come from the request
- * @edit edit directly
- *
- * THE DOCUMENT'S OWN FACTS, DERIVED WHERE THEY ARE KNOWN: the service
- * names itself, and the request knows where it arrived. Deriving rather
- * than configuring is what makes ONE document correct for the internal
- * address the MCP gateway uses and for a public host at the same time
- * (`information-exists-in-one-location` — the request is the only place
- * the reachable address exists).
- *
- * The `/api/rpc` prefix is part of the answer, not an accident of the
- * mount: it is the prefix the POST handler serves under, so a client that
- * reads the document can call what the document describes.
+ * @status handwritten
  */
 
 /**