All runbooks
runbookuapiredacted view

UAPI GLM 5.2 Scaffold Target Gate

GLM Worker F comparison of UAPI scaffold target options; recommends a new isolated UAPI repo.

Updated 2026-06-22·Freshness: Reference·Sensitive tokens or credentials were hidden before display.

UAPI GLM 5.2 Scaffold Target Gate

GLM Worker F comparison of UAPI scaffold target options; recommends a new isolated UAPI repo.

Promotion Metadata

  • Source feedback id: 159
  • Source feedback ids: 159
  • Promotion request id: 90
  • Feedback category: consider
  • Feedback source: ai-lane
  • Feedback created at: 2026-06-22T20:07:33.186203+00:00
  • Target slug: [REDACTED:high-entropy]
  • Review state: review
  • Reviewer note: AI lane auto-promoted redacted feedback into internal catalog context.

Source Feedback Body

Feedback 159

  • Product: uapi
  • Category: consider
  • Related slug: ``
  • Source: ai-lane
  • Created at: 2026-06-22T20:07:33.186203+00:00

GLM 5.2 UAPI Scaffold Target Gate (2026-06-22)

Created: 2026-06-22T20:10:00Z Authority: GLM Worker F scaffold evaluation. No code edits, no repo mutations.

Target Options Compared

A: New Isolated UAPI Repo

  • Pros: clean boundary, Codex owns schema from day one, rollback = delete repo.
  • Cons: no existing infra; CI/lint/deps from scratch; longest setup.
  • Blast radius: zero (nothing depends on it yet).

B: Thinktank Fixture-Derived Package

  • Pros: reuses policy vocabulary (Device, PlacementDecision, RunRecord); has schema validator and tests.
  • Cons: Thinktank repo dirty with pending changes; runbook says fixture-only/no-execution; promoting to production risks scope creep; couples to Thinktank release cycle.
  • Risk: medium — violates fixture-only constraint if not carefully bounded.

C: UAI-Director/Command-Center Surface

  • Pros: has server infra; already an operator coordination surface.
  • Cons: Director is Cadence coordination, not UAPI; conflates bounded contexts; no UAPI schema ownership.
  • Risk: high — coupling UAPI to Director merges two separate domains.

D: Discovered Remote Repo

  • Pros: natural target if a real UAPI service exists.
  • Cons: no confirmed production repo found (see target-discovery diary); GitHub search returned zero matches; Grok still mapping lab routes.
  • Risk: unknown — target does not yet exist.

Decision Criteria

Criterion A B C D
Language/runtime isolation Y ~ N ?
Auth boundary clarity Y ~ N ?
Schema ownership (Codex) Y ~ N ?
Event sink abstraction Y Y N ?
Run ledger ownership Y ~ N ?
Storage adapter boundary Y Y N ?
Explorer evidence export Y Y ~ ?
Rollback safety Y N N ?

Y = strong, ~ = partial, N = no, ? = unknown.

Recommendation

Option A: New isolated UAPI repo is the safest first implementation target.

Rationale: cleanest auth/session boundary; Codex owns v0.2 contracts unambiguously; rollback is trivial; Thinktank vocabulary can be referenced (not imported) for naming without coupling; Director and remote repos remain future integration targets.

Option B is viable for a second iteration if Codex extracts a bounded package, but not as the first wedge.

Sources

  • [REDACTED:high-entropy].md
  • [REDACTED:high-entropy].md
  • [REDACTED:high-entropy].md
  • [REDACTED:high-entropy].md

Assumptions

  • Codex creates/assigns the target repo; GLM does not create repos.
  • Language choice deferred to Codex (TS/Python/Rust all viable).
  • v0.2 contracts are authoritative; no v0.3 expected before first wedge.

Blockers

  • No target repo exists — Codex must create or assign one.
  • No auth/session store chosen — mock required for first wedge.
  • Forge SN850X storage not policy-approved — candidate only.
  • GitNexus MCP unavailable for impact checks in this session.

Next Handoff

  1. Codex: create/assign target repo; confirm language/runtime.
  2. GLM: apply first-wedge test plan (companion diary) once repo exists.
  3. Grok: complete remote lab route mapping for future Option D evaluation.