Adds §11 to the v3 cross-repo UX roadmap: a 202-item, machine-parsable
checklist that coding agents flip as they ship work, with the
`learning_ai_uxui_web` showcase as the canonical visual-iteration
surface ahead of any product adoption.
──────────────────────────────────────────────────────────────────
§11 — Showcase-first workflow & live progress tracker
──────────────────────────────────────────────────────────────────
\u00a711.0 The showcase-first rule (non-negotiable 7-step recipe)
1. Scaffold in common_plat/packages/<name>/
2. Vendor snapshot to learning_ai_uxui_web/src/lib/<name>-preview/
3. Showcase route at src/app/showcase/<group>/<slug>/page.tsx
+ catalog entry in src/catalog/routes.ts
4. MSW mock any backend dependency
5. Smoke test (axe + visual-regression baseline)
6. Publish to Gitea registry; delete preview; swap imports
7. Adopt in ≥ 1 product — that PR closes the checklist row
\u00a711.1 Agent update protocol — flip `- [ ]` → `- [x]` inline with
the commit; trail the short-SHA in parentheses; multi-step
rows tracked sub-bullet by sub-bullet.
\u00a711.2 Live "Progress at a glance" block (auto-rewritten by the
counter script below).
\u00a711.3 Wave 8 Rollout — 18 items
\u00a711.4 Wave 9 Data — 42 items
\u00a711.5 Wave 10 Shells — 35 items
\u00a711.6 Wave 11 Adaptive — 26 items
\u00a711.7 Wave 12 Mobile — 26 items
\u00a711.8 Wave 13 Futurism — 39 items
\u00a711.9 Cross-cutting — 8 items
\u00a711.10 Customer-magnet demos — 8 items
───────────────────────────────
TOTAL — 202 items
Every package row carries a paired "**Showcase:**` /showcase/...`"
route entry so agents know exactly where the demo lives. Cross-
referenced with the per-product upgrade matrix in §5.
Renumbered hygiene §11 → §12. Header bumped v3.1 → v3.2.
──────────────────────────────────────────────────────────────────
scripts/count-roadmap-progress.ts
──────────────────────────────────────────────────────────────────
TypeScript node script (tsx) that:
- Parses the v3 doc, counts `- [ ]` and `- [x]` per §11.x section
- Rewrites the §11.2 fenced block in place with live counts +
bar charts + percentages
- Updates the `· \`N / M\`` suffix on every `### 11.x Wave …`
heading so per-wave totals stay accurate
- Idempotent: re-runs are no-ops when nothing changed
- Verified: emits `0 / 202 done` on initial run; "up to date"
on second run
Wired as Wave 8.A.7 (also tracked at CC.8 — should land in pre-commit
hook so the §11.2 block can never drift from reality).
Mirror in copilot/learning_ai_uxui_web follows in a paired commit.
═══════════════════════════════════════════════════════════════════════
TODO #6 — size-limit budgets in CI
═══════════════════════════════════════════════════════════════════════
Adds .size-limit.cjs with budgets for 6 pilot @bytelyst/* packages,
plus a Gitea Actions workflow (.gitea/workflows/size-limit.yml) that
fails the build on any regression.
Current measurements vs budget (all comfortably under):
@bytelyst/api-client 793 B / 8 KB
@bytelyst/auth-client 1.97 KB / 8 KB
@bytelyst/celebrations 236 B / 6 KB
@bytelyst/quick-actions 122 B / 6 KB
@bytelyst/react-auth 2.71 KB / 10 KB
@bytelyst/dashboard-shell 3.96 KB / 30 KB
Scripts:
pnpm size — measure + assert against budgets
pnpm size:why — explain top contributors
Deps: size-limit@^12.1.0, @size-limit/preset-small-lib@^12.1.0.
Pilot scope (this commit): 6 packages. Full @bytelyst/* rollout is
incremental — each entry added separately.
═══════════════════════════════════════════════════════════════════════
TODO #5 — Storybook canonical pattern
═══════════════════════════════════════════════════════════════════════
Discovery: @bytelyst/ui already has Storybook 8 with the @bytelyst/
addon-a11y addon configured and 5 .stories.tsx files.
This commit:
- Documents that setup as the canonical template
(docs/STORYBOOK_TEMPLATE.md) including the .storybook/main.ts,
preview.ts, package.json scripts, and an example story.
- Catalogs which of the 8 visual @bytelyst/* packages need Storybook
added (1/8 done — @bytelyst/ui).
- Per docs/ROADMAP_2026_DECISIONS.md §9, hosting target is
self-hosted Gitea Pages (no Chromatic).
Full rollout to the other 7 packages stays open as incremental work.
═══════════════════════════════════════════════════════════════════════
TODO #4 — DTCG v3 token migration RFC
═══════════════════════════════════════════════════════════════════════
This is too large to land in a single commit. Drafted RFC instead:
docs/rfc/0001-dtcg-v3-token-migration.md
The RFC proposes a 4-PR sequence:
PR 1 — Add converter + dual-emit (byte-identical assertion)
PR 2 — Flip source of truth to DTCG JSON
PR 3 — Introduce the component tier
PR 4 — Multi-theme via DTCG token sets
Estimate: 2 person-weeks total. Backward compatibility: --ml-* and
--bl-* names preserved through all 4 PRs. Status: Draft, awaiting
reviewers.
Refs: learning_ai_uxui_web/docs/ROADMAP_2026.md §10 TODOs #4, #5, #6
Three coordinated package changes addressing Wave 1 cross-repo TODOs
from the UI/UX roadmap (learning_ai_uxui_web/docs/ROADMAP_2026.md §10).
═══════════════════════════════════════════════════════════════════════
TODO #2 — @bytelyst/react-auth bump 0.1.8 → 0.2.0
═══════════════════════════════════════════════════════════════════════
- Changes 'workspace:*' to 'workspace:^' for the @bytelyst/api-client
dependency. On pnpm publish this resolves to a caret range (e.g.
^0.1.6) instead of '*', restoring installability for consumers.
(The 0.1.6 tarball was published with a literal 'workspace:*'
string — newer minor bump unblocks the showcase react-auth demo.)
- 21 tests still passing.
═══════════════════════════════════════════════════════════════════════
TODO #3 — @bytelyst/dashboard-shell bump 0.1.7 → 0.2.0
═══════════════════════════════════════════════════════════════════════
- Adds 'routePrefix?: string' prop to DashboardShellProps, SidebarProps,
and TopBarProps. Threads through DashboardShell → Sidebar + TopBar.
- Built-in /profile, /billing, /settings links now use the prefix:
routePrefix="/app" → /app/profile, /app/billing, /app/settings
- Defaults to '' (empty string) — fully back-compat with 0.1.x callers.
- 2 new vitest cases covering both prefixed and default behavior;
43 / 43 tests passing (+2 from 41).
═══════════════════════════════════════════════════════════════════════
TODO #1 — @bytelyst/design-tokens bump 0.1.8 → 0.2.0
═══════════════════════════════════════════════════════════════════════
- Adds a density-aware spacing tier on top of the existing raw
--ml-space-* tier:
--bl-space-scale: 1 (default :root)
--bl-space-1..16: calc(--ml-space-N × --bl-space-scale)
- Emits density selectors at the end of tokens.css:
[data-density="compact"] { --bl-space-scale: 0.875; }
[data-density="comfortable"] { --bl-space-scale: 1; }
[data-density="spacious"] { --bl-space-scale: 1.125; }
- Generator (scripts/generate.ts) emits both tiers automatically; the
auto-generated per-product CSS files (lysnrai, mindlyst, etc.) gain
a single blank-line diff from regeneration — no semantic change.
- 11 / 11 token tests passing.
═══════════════════════════════════════════════════════════════════════
Decision doc — docs/ROADMAP_2026_DECISIONS.md
═══════════════════════════════════════════════════════════════════════
- Records pragmatic defaults for TODO ledger items #9–#13 so
implementation work doesn't block:
#9 Storybook hosting → self-hosted on Gitea Pages (free)
#10 useChat protocol → adopt Vercel AI SDK shape, abstract transport
#11 react-auth fold-in → defer to Wave 7
#12 dashboard-shell merge → defer to Wave 7
#13 mobile-native UI → out of scope (tokens-only sharing)
- Each decision is reversible via RFC.
═══════════════════════════════════════════════════════════════════════
Publish flow
═══════════════════════════════════════════════════════════════════════
These three packages now require a release. The existing publish
workflow (.gitea/workflows/publish-packages.yml) has PACKAGE_FILTER
pinned to @bytelyst/errors and won't pick them up automatically — a
manual workflow_dispatch with a broader filter (or the existing
publish-all-packages.yml on workflow_dispatch) is needed to ship
0.2.0 to the Gitea npm registry.
Refs: learning_ai_uxui_web/docs/ROADMAP_2026.md §10 TODOs #1, #2, #3, #9–#13
Copy-pasteable runbook for the case where:
- VM is already provisioned
- Gitea is already installed and running on :3300
- Repos are already cloned on the VM
- User needs to wire admin + npm-user + token + laptop end-to-end
10 numbered steps with expected outputs and troubleshooting:
1. Create Gitea admin user (idempotent skip if exists)
2. Create npm owner user (learning_ai_user)
3. Mint npm-scoped token via API
4. Write token to ~/.gitea_npm_token_home on laptop
5. Update ~/.gitea_vm_host with VM hostname
6. Pre-flight verification via doctor.sh (expects 404 on probe)
7. Publish @bytelyst/* via publish-local-packages.sh
8. End-to-end verification (re-run doctor + smoke-test pnpm install)
9. Optional: backfill historical versions
10. Persist environment in ~/.zshrc
Includes troubleshooting table, persistence map (what survives VM reboot
vs rebuild), and Azure NSG/firewall guidance.
Companion to scripts/gitea/{bootstrap-vm,doctor,token}.sh.
Moves 5 related docs into docs/devops/gitea-runner/ to keep this
multi-doc workstream from colliding with future roadmaps and
delegation prompts in docs/devops/.
Renames:
HOSTINGER_GITEA_RUNNER_ROADMAP.md -> ROADMAP.md
HOSTINGER_GITEA_ACT_RUNNER_SETUP.md -> ACT_RUNNER_SETUP.md
GITEA_PACKAGES_PUBLISH_WORKFLOW.md -> PUBLISH_WORKFLOW.md
HOSTINGER_GITHUB_RUNNER_SETUP.md -> _PLAN_B_GITHUB_RUNNER.md
CODEX_DELEGATION_PROMPT.md -> (same name, moved)
All internal cross-links updated via sed sweep. Verified no stale
references remain.
Adds README.md in the new folder as the index + pattern doc for
future multi-doc workstreams (one-liner handoff, file map,
architecture summary).
Updated one-liner handoff path:
Read docs/devops/gitea-runner/CODEX_DELEGATION_PROMPT.md ...
Captures the exact bootstrap prompt to paste to Codex on the
Hostinger VM, plus a one-liner that just points Codex at the prompt
file (after Codex has the repo).
Also documents how to monitor Codex's progress from Cascade side
(grep roadmap-update commits) and how to recover if it gets stuck
(the checkbox state in the roadmap IS the resume pointer).
Adds HOSTINGER_GITEA_RUNNER_ROADMAP.md — a single execution tracker
that Codex on the Hostinger VM works through phase-by-phase, ticking
checkboxes and recording commit hashes as it goes.
Structure:
- 6 phases (P0 Pre-flight → P5 First real release) + P6 review handoff
- Each task: [ ] checkbox + Commit hash field + Status note
- Detail steps live in the two companion docs (act_runner setup +
publish workflow); the roadmap is the orchestrator
- Final report section Codex fills in when P0-P5 are complete
- Human review checklist (R1-R9) for verification after handoff
- Operating notes: commit message format, when to ask, never-do list
- Change log table Codex auto-appends to
Critical invariant repeated at P3.6 and P5.4: cross-Gitea SHA1
comparison must match. If it doesn't, Codex stops — it's the
load-bearing architectural guarantee that the dual-Gitea, no-sync-
script model rests on.
Also adds roadmap-pointer banners to the two companion docs
(HOSTINGER_GITEA_ACT_RUNNER_SETUP.md, GITEA_PACKAGES_PUBLISH_WORKFLOW.md)
so anyone landing there knows the master tracker exists.
Adds two new docs and a banner on the existing GitHub-runner doc.
WHY: the user already has Gitea Actions configured across all 20+
repos (.gitea/workflows/ci.yml). Building a parallel GitHub Actions
self-hosted runner pipeline is unnecessary work that also drags in
GitHub Organization migration pressure (with Vercel/Netlify pricing
side-effects on free tiers).
The canonical architecture instead:
- Each Gitea instance (corp Mac local + Hostinger VM) runs its own
act_runner.
- A single publish-packages.yml workflow lives in every package-
publishing repo.
- When the same git tag is pushed to both Giteas, each one builds
inside the same pinned Docker image (node:20-bookworm@sha256:...)
with the same lockfile, producing BYTE-IDENTICAL tarballs.
- No sync script is needed; the shared git tag IS the sync mechanism.
- Lockfile integrity hashes match across both registries, so corp Mac
and personal Mac + Hostinger prod all see the same packages.
New: HOSTINGER_GITEA_ACT_RUNNER_SETUP.md
- Codex-actionable prompt to install act_runner on the Hostinger VM
- Pre-flight checks (arch detection, Docker daemon, Gitea reachable)
- Idempotent user creation, SHA-verified binary download
- Docker mode runner config with labels mapping ubuntu-latest to
pinned Node image
- Smoke test + full E2E with throwaway @bytelyst/_runner-e2e-test
package
- The architectural invariant check: cross-Gitea SHA comparison —
same tag pushed to both must produce identical tarballs
- Monitoring (Gitea UI, API, systemd journal)
- Hardening, rollback, deliverables, guardrails, questions
New: GITEA_PACKAGES_PUBLISH_WORKFLOW.md
- The actual publish-packages.yml triggered by v* tags
- Docker image pinned by digest for build determinism
- pnpm@9.12.0 pinned, --frozen-lockfile, host-network container
- Token mounted as read-only secret file (not env var)
- Concurrency cancel-in-progress: false (never cancel a publish)
- Pack tarballs + SHA512 manifest as Gitea Release assets for audit
trail
- Two propagation strategies: reusable workflow (preferred) vs
sync-publish-workflow.sh script
- Operator runbook for cutting a release
- Failure-mode table + remediation
- Deliverables checklist
Updated: HOSTINGER_GITHUB_RUNNER_SETUP.md
- Added 'PLAN B' banner at the top
- Cross-links to the Gitea Actions docs
- Kept the doc intact as a valid alternative if priorities ever
shift to making GitHub Actions the publish driver
Adds the missing pieces revealed during review:
§1 Multi-repo registration decision — choose repo-level vs org-level
up-front. Default doc remains repo-level, but explicitly calls out
org-level as the scaling path for 20+ repos.
§2 Pre-flight check additions:
- Arch detection (x86_64 / aarch64) before downloading runner tarball
- github.com + objects.githubusercontent.com reachability check
- gh CLI auth status check (must be saravanakumardb1)
§4 Installation hardening:
- Step 1 is now idempotent (getent guards on useradd/usermod)
- Step 3 queries latest runner version via gh api (no more stale pin)
- Step 3 includes SHA256 verification of the downloaded tarball
against the release-notes manifest, with explicit STOP-if-mismatch
- Step 3 has REGISTRATION_URL var with commented Option A/B for
repo-level vs org-level scope
§5 Smoke test — added explicit git checkout/add/commit/push commands
for creating the runner/smoke branch (was implicit before).
§8 (renamed) — comprehensive org migration guide:
- Side-by-side table: personal account today vs under-an-org
- Bash loop to transfer all 18 repos via gh api
- git remote set-url commands for each local clone
- Post-migration org-level registration token fetch
- Workflow propagation strategies (reusable workflow vs sync script)
§9 (new) — Monitoring + observability:
- GitHub Actions tab per-repo + per-org workflow views
- Runner pool health (Settings → Actions → Runners) at repo + org level
- gh CLI commands for scripted monitoring (run watch, list, view, runners)
- Host-side journalctl + _diag/ inspection commands
§14 Questions — updated to ask about scope (repo vs org) first.
Section numbering shifted by +1 from §9 onward to make room for the
new Monitoring section.
