Platform Modernization — V3 Build-Out Playbook (T7 / T8 / T9)

File: docs/playbooks/v3-platform-modernization-playbook.md Base branch: dev (integration branch — main stays protected/production; PRs target dev) Branch naming: feature/<ado-task-id>-<slug>-v3-pr<n> — ADO task IDs: T7=112511, T8=112510, T9=112512 (see work-items/). Plan date: 2026-07-23 Owner: Sultan — all three tasks in this playbook (T7, T8, T9). Priority: this playbook’s work must land on dev before the remaining tasks in docs/playbooks/v2-team-velocity-playbook.md (T3/T5/T6, owner Fatima) resume. Rationale: T9 replaces the public/ static-page shell those tasks would otherwise build UI against (T5’s chat widget, T6’s KPI card) — building on the soon-to-be-replaced shell means redoing that UI work twice. Source: new scope, not from the original design doc — added 2026-07-23.

How to Use This Document

Three new tasks, none of which existed in the v1/v2 playbooks:

T7 — UI responsiveness across all screen resolutions, including mobile. The current public/ shell (Developer Productivity Dashboard.dc.html port) was built and verified at desktop width only (per v1-dev-productivity-dashboard-playbook.md PR-0) — no breakpoints, no mobile layout.
T8 — BOLDVelocity branding: image-generation prompts (for whatever asset-generation tool is available — Midjourney/DALL·E/etc.) to produce a logo, favicon, and supporting brand assets for “BOLDVelocity,” matching the AlphaBOLD logo’s existing theme/colors (assets/alphabold-logo.png — warm off-white, near-black text, gold #E3AD21/#CB9328 accent). This task’s deliverable is primarily the prompts themselves plus wiring the generated assets into the project once produced — not the image generation itself, which happens outside Claude Code.
T9 — Migrate public/ from a dependency-free static page to Vue 3 + Vite, with vue-router (decided — see “Framework/routing decision” below). Justified because the app is not handling multiple pages today and was intentionally built framework-free (Ponytail rung 4: native platform features over dependencies) — this migration is scoped because component reuse (T7’s responsive layouts) and client-side routing between the dashboard and contributor detail view now outweigh that original simplicity call.

Build order differs from task numbering. Task IDs (T7/T8/T9) match the order the user listed them in; actual branch/merge order is T9 → T7 → T8:

T9 first — migrating the shell’s markup/component structure before writing responsive CSS or wiring in new brand assets avoids doing that work once against the current public/dashboard.js and again after migration.
T7 second, stacked on T9 — responsive breakpoints are written against the migrated framework’s component structure, not the soon-to-be-replaced plain-DOM shell.
T8 third, stacked on T7 — brand assets (logo/favicon/head tags) are wired into the final, responsive, migrated shell once, not touched twice.

If a real, urgent need for T8’s assets shows up sooner (e.g. a stakeholder demo), it can be generated and merged independently at any time — the design-asset generation itself has no dependency on T9/T7. Only the wiring into the app benefits from doing it last.

Framework choice — Next.js vs Vue

Neither is chosen yet. Decide based on what’s already true of this codebase and team, not a generic framework debate:

Question	If yes → lean	If no → lean
Does the team already know React (this repo’s design canvas was React/Babel via `support.js`)?	Next.js	Vue
Is SSR/static-export or file-based routing wanted even though the app is single-page today?	Next.js	Vue (Vite) is lighter for a pure SPA
Is the smallest possible build/toolchain footprint the priority (Ponytail rung 4/5)?	—	Vue + Vite has a smaller default footprint than Next.js

Default recommendation: Vue (via Vite) — the app is explicitly a single page today (per this task’s own framing, “not handling multiple pages”), so Next.js’s routing/SSR machinery is mostly unused weight; Vue + Vite gets component reuse and a dev server with the smallest addition over the current zero-dependency setup. Revisit if the team has a strong existing React preference — the design canvas’s React/Babel usage was CDN-loaded for the stakeholder-review artifact only (support.js, Developer Productivity Dashboard.dc.html), not a signal of team framework preference for the production shell.

Framework/routing decision — DECIDED (2026-07-23)

Vue 3 + Vite, with vue-router for client-side routing. Locked in; do not re-litigate in PR-7/8/9.

Why Vue + Vite: matches the default recommendation above — single-page app today, no documented team React preference, smallest toolchain footprint (Ponytail rung 4/5).
Why add vue-router (not in Vite’s minimal template by default): today’s nav from the dashboard to a contributor’s detail view is two separate static pages (public/index.html → public/contributor.html) linked via a plain <a href="contributor.html?email=..."> (dashboard.js:555) — a full page reload, with filter/contributor state passed only through the URL query string and re-parsed from scratch on load (contributor.js:8-9). vue-router replaces that with two client-side routes (/ and /contributor) navigated via <router-link>/router.push — no full reload, state/fetched data can be shared across the nav instead of every contributor-view visit cold-starting its fetches.
Contract preserved: query-string params (email, apiBase, mock, filter params) stay the shareable/back-linkable mechanism — routes read from route.query, same shape as today’s URLSearchParams reads. No change to api/server.py routes or aggregate()’s output shape.
Infra impact: none. vue-router is a build-time npm dependency only — the build still outputs a static SPA bundle (dist/), served by the same single-process/single-port api/server.py static handler (_STATIC_PREFIXES) already deployed via the existing Dockerfile/azure-pipelines.yml. No new Azure resource, service connection, or runtime process — see PR-7’s “Required change” step 1 for the one Dockerfile change this does require (a Node build stage).

1. Executive Summary

#	Item	Gap	Depends on
T7	No responsive layout	`public/dashboard.css` targets desktop width only; no breakpoints for tablet/mobile	T9 — DONE (build against migrated components, not the shell being replaced)
T8	No BOLDVelocity brand identity	Dashboard currently only carries the AlphaBOLD logo (`assets/alphabold-logo.png`); no BOLDVelocity-specific logo, favicon, or asset set exists	T7 (wire assets into the final responsive shell once)
T9	Static page, no framework	`public/` is plain HTML/CSS/JS by original design (Ponytail rung 4) — migrate to Vue 3 + Vite + `vue-router` since the single-page assumption behind that call is being revisited	DONE — merged to `dev`

PR Strategy — 3 PRs, stacked T9 → T7 → T8

PR-7 carries T9: framework migration. Branched from dev. DONE — implemented and merged directly to dev (PR 2404).
PR-8 carries T7: responsive layout. Branches from dev (PR-7 already merged there — no need to branch from PR-7’s now-closed branch).
PR-9 carries T8: BOLDVelocity branding assets + integration. Branches from PR-8 (wires assets into the final responsive shell).

(PR numbers continue from the parent playbooks’ PR-0..PR-6 — PR-7/8/9 here, not reused.)

Merge Sequencing

~~PR-7 (T9) merges to dev first.~~ DONE.
PR-8 (T7) branches from dev (not PR-7’s branch — already merged), merges next.
PR-9 (T8) stacks on PR-8, merges third.
Only after PR-9 merges does v2-team-velocity-playbook.md’s T3/T5/T6 work resume.

Model Guidance

PR	Task	Recommended Model	Effort	Reason
PR-7	T9 (Vue + Vite + vue-router migration)	Sonnet 5	medium-high	Full rewrite of `public/dashboard.js`’s plain-DOM rendering into Vue components plus client-side routing, while preserving `mockData.js`/API data-shape contract and every existing interaction (filters, sort, charts)
PR-8	T7 (responsive layout)	Sonnet 5	low-medium	CSS breakpoints + layout reflow on an already-componentized shell; no new data logic
PR-9	T8 (branding integration)	Sonnet 5	low	Mostly prompt-writing (outside Claude Code) plus dropping generated assets into the app and updating head tags/logo references

2. PR Plan

PR	Branch	Items	Branches from	Est.	Status
PR-7	`feature/112512-nextjs-vue-migration-v3-pr7`	T9	`dev`	1–2 weeks	DONE — merged to `dev`
PR-8	`feature/112511-responsive-layout-v3-pr8`	T7	`dev`	3–5 days	Next up
PR-9	`feature/112510-boldvelocity-branding-v3-pr9`	T8	PR-8’s branch	2–3 days	Not started

ADO task IDs: T9=112512, T7=112511, T8=112510 (see work-items/).

3. Files Touched

File / path	PR
`public/` (entire directory — re-platformed onto a Vue + Vite project structure)	PR-7 (T9)
`package.json`/`vite.config.*` (new — build tooling)	PR-7 (T9)
`public/src/router/` (new — `vue-router` route table: `/`, `/contributor`)	PR-7 (T9)
`public/dashboard.css` (or framework-equivalent stylesheet) — breakpoints added	PR-8 (T7)
`assets/boldvelocity-logo.`, `assets/boldvelocity-favicon.` (new)	PR-9 (T8)
`docs/branding/boldvelocity-asset-prompts.md` (new — the image-generation prompts themselves, kept as a reference so assets can be regenerated/iterated later)	PR-9 (T8)
App shell’s `<head>`/layout component (favicon link, logo reference)	PR-9 (T8)

4. Hard Rules

(Inherits Hard Rules 1–3, 6, 8–10, 12 from docs/playbooks/v1-dev-productivity-dashboard-playbook.md §4 — metric definitions, no LLM calls in connector/store/API layers, blended AI-assisted % labeling, storing aggregates not raw payloads, team-baseline framing, no Claude co-author trailer, ADO-hosted repos, and no automatic git actions (stage/commit/push only on explicit user approval, no PR opened). The following are additive, specific to this playbook.)

No data-shape changes. T9’s migration must preserve the exact aggregate() output shape (teamRows, kpis, repoBars, velocityPoints, columns, etc.) that api/server.py and mockData.js already produce — this is a rendering-layer migration, not a data-layer one. store/, api/, and connectors/ are out of scope for all three tasks in this playbook.
No regression in existing interactions. Every filter (project/tool/date-range), sortable column, and chart that works in the current public/dashboard.js must still work after T9’s migration and T7’s responsive pass — verify each one manually post-migration, not just that the page renders.
T8’s assets must be generated, not hand-drawn placeholders. If no image-generation tool is available in a given session, ship the prompts (docs/branding/boldvelocity-asset-prompts.md) and leave the current AlphaBOLD logo in place rather than committing a low-effort SVG/text placeholder — an honest gap beats a fake brand asset.
Framework/routing choice is decided, not re-litigated. Vue 3 + Vite + vue-router (see “Framework/routing decision” above) — PR-7 implements it, PR-8/PR-9 build on it as-is.
Developer Productivity Dashboard.dc.html and support.js stay untouched — same rule as the parent playbooks; they remain the stakeholder-review canvas, independent of public/’s implementation.

PR 7 — Migrate `public/` from static HTML/JS to Vue + Vite + vue-router (T9)

Status: DONE (2026-07-24) — implemented and merged directly to dev (PR 2404, branch feature/112512-nextjs-vue-migration-v3-pr7). PR-8 now branches from dev, not this branch.

Branch: feature/112512-nextjs-vue-migration-v3-pr7 Branches from: dev Model: Sonnet 5 Effort: medium-high

Problem

public/index.html/public/dashboard.js/public/dashboard.css were deliberately built dependency-free (Ponytail rung 4 — native platform features over a framework) because the app was, and still is, a single page. That simplicity call is being revisited now that T7’s responsive work and T8’s branding work are coming — component reuse and a proper build/dev toolchain reduce the risk of those two follow-on tasks duplicating markup across breakpoints or brand-asset references by hand. Separately, today’s nav from the dashboard to a contributor’s detail view (public/index.html → public/contributor.html via a plain <a href>, dashboard.js:555) is a full page reload with state passed only through the URL query string (contributor.js:8-9 re-parses it from scratch). See “Framework/routing decision” above — decided: Vue 3 + Vite + vue-router, not re-litigated in this PR.

Required change

Stand up a Vue 3 + Vite minimal project scaffold inside public/ (or a new top-level app directory if Vite’s conventions require it — smallest footprint the template allows, not a full Nuxt/enterprise starter). Add vue-router as a dependency.
Define two client-side routes: / (dashboard) and /contributor (detail view), reading email/apiBase/mock/filter params from route.query (same shape as today’s URLSearchParams reads — still shareable/back-linkable via URL). Replace the dashboard’s <a href="contributor.html?..."> row link with <router-link>/router.push so navigation is client-side (no full reload).
Port every existing visual element (top bar, KPI row, velocity + composition charts, team table, secondary row, contributor detail panel) into components, preserving the exact DOM structure/classes dashboard.css already targets where practical, to minimize CSS rewrite risk for T8.
Preserve the existing data-fetching contract exactly: calls to api/server.py’s routes (or the ?mock=1 / mockData.js fallback path) with the same filter shape (project, tool, date-range, sort). No changes to store/, api/, or connectors/.
Preserve every interaction: project/tool/date filters, sortable column headers, chart rendering, dashboard→contributor→back navigation — verify each manually against the pre-migration shell before calling this done.
Update USAGE.md with Vite’s dev-server/build commands, replacing (not just appending to) the plain-static-server instructions for public/. Leave the .dc.html canvas instructions untouched.
Add a Vitest smoke test asserting the root component mounts and renders the KPI row from a fixture, plus one asserting the /contributor route resolves with a query param — no large test-framework scaffolding beyond that.
Update the Dockerfile to a multi-stage build: a node:alpine stage runs npm ci && npm run build, then the final python:3.12-alpine stage copies the built dist/ output in place of raw public/ source. Point api/server.py’s _STATIC_PREFIXES/static root at dist/. No change to azure-pipelines.yml, the ACR, the Web App, or any service connection — same single docker buildAndPush + AzureWebAppContainer@1 deploy, same single process/port.

Prompt — paste verbatim into Claude Code

You are implementing PR-7 of the Platform Modernization playbook
(docs/playbooks/v3-platform-modernization-playbook.md).

Read the full PR-7 section and this playbook's "Framework/routing decision"
subsection before writing any code. Read public/dashboard.js, public/
contributor.js, public/index.html, public/contributor.html, and public/
dashboard.css in full first — this is a rendering migration, every
existing interaction must survive it unchanged.

Branch: feature/112512-nextjs-vue-migration-v3-pr7 from dev.

Scope — T9 ONLY: migrate public/'s rendering layer to Vue 3 + Vite with
vue-router (decided — see "Framework/routing decision", not up for
re-decision here). Do NOT modify store/, api/, or connectors/ — the
data-shape contract (aggregate()'s output shape) must stay byte-for-byte
identical. Do NOT touch "Developer Productivity Dashboard.dc.html" or
support.js.

═══════════════════════════════════════
STEP 1 — Scaffold + routing
═══════════════════════════════════════

1. Stand up a Vue 3 + Vite minimal project scaffold. Add vue-router. Keep
   the dependency footprint as small as the template allows.
2. Define two routes: / (dashboard) and /contributor (detail view), reading
   email/apiBase/mock/filter params from route.query (same shape as
   today's URLSearchParams reads). Replace the dashboard's
   <a href="contributor.html?..."> row link with <router-link>/router.push
   for client-side navigation (no full page reload).

═══════════════════════════════════════
STEP 2 — Port components
═══════════════════════════════════════

3. Port each visual section (top bar, KPI row, velocity chart, composition
   chart, team table, secondary row, contributor detail panel) into
   components, preserving existing class names/DOM structure from
   dashboard.css where practical.
4. Preserve the existing fetch layer (api/server.py calls, ?mock=1 /
   mockData.js fallback) and all filter/sort state handling — same
   behavior, not necessarily the same code shape.

═══════════════════════════════════════
STEP 3 — Verify parity
═══════════════════════════════════════

5. Manually confirm every pre-migration interaction still works: project
   filter, tool filter, date-range picker, sortable columns, chart
   rendering, ?mock=1 fallback, dashboard→contributor→back navigation.
6. Add Vitest smoke tests: root component mounts and renders the KPI row
   from a fixture; /contributor route resolves with a query param.
7. Update USAGE.md with Vite's dev-server/build commands for public/,
   leaving the .dc.html canvas instructions untouched.

═══════════════════════════════════════
STEP 4 — Docker/deploy
═══════════════════════════════════════

8. Update the Dockerfile to a multi-stage build (node:alpine build stage →
   copy dist/ into the python:3.12-alpine final stage). Point
   api/server.py's static root/_STATIC_PREFIXES at dist/. Do not touch
   azure-pipelines.yml — same single docker buildAndPush +
   AzureWebAppContainer@1 deploy, no new Azure resources.

═══════════════════════════════════════
Verification
═══════════════════════════════════════

9. Run the Vite dev server, load the dashboard, manually confirm parity
   per STEP 3.
10. Run the Vitest suite. No failures.

Once implementation is complete and all tests pass, STOP. Do not stage,
commit, or push anything — confirm with the user first.

On user approval only:
  1. git add -A (stage all files).
  2. Commit via the commit-msg skill.
     Suggested title: "feat: platform PR-7 — migrate public/ to Vue + Vite + vue-router (T9)"
     Resolves: #112512
  3. git push -u origin feature/112512-nextjs-vue-migration-v3-pr7. No PR to open.

No Co-authored-by: Claude trailer.

PR 8 — Responsive layout for all screen resolutions, including mobile (T7)

Status: next up — PR-7 (T9) is merged to dev, so branch this from dev directly.

Branch: feature/112511-responsive-layout-v3-pr8 Branches from: dev (PR-7 already merged there) Model: Sonnet 5 Effort: low-medium

Problem

The dashboard’s layout (top bar, KPI row, main row with charts, team table, secondary row) was verified at desktop width only. No breakpoints exist for tablet or mobile; the team table in particular is unusable on narrow viewports without a responsive strategy (horizontal scroll or column collapse).

Required change

Add breakpoints (mobile ≲480px, tablet ≲768px, desktop above) to the migrated stylesheet: KPI row wraps/stacks instead of overflowing, charts resize to container width, the team table gets a horizontal-scroll container or a collapsed/stacked-row mobile variant (pick one and apply consistently — do not build both).
Filter controls (project/tool/date-range) collapse into a mobile-friendly control (e.g. a dropdown/sheet) below tablet width rather than staying a fixed-width row.
Verify with the browser’s device toolbar at a small representative set of widths (e.g. 375px, 768px, 1024px, 1440px) — not just resizing the window once.
No data/interaction regressions — every filter/sort/chart interaction from PR-7 must still work at every breakpoint.

Prompt — paste verbatim into Claude Code

You are implementing PR-8 of the Platform Modernization playbook
(docs/playbooks/v3-platform-modernization-playbook.md).

Read the full PR-8 section before writing any code. PR-7 (T9, framework
migration) is already merged to dev — read the migrated
component/stylesheet structure in full first.

Branch: feature/112511-responsive-layout-v3-pr8 from dev.

Scope — T7 ONLY: responsive breakpoints and mobile-friendly layout. Do not
change data-fetching logic, component structure beyond what responsiveness
requires, or touch store/, api/, or connectors/.

═══════════════════════════════════════
STEP 1 — Breakpoints
═══════════════════════════════════════

1. Add mobile (~480px)/tablet (~768px)/desktop breakpoints to the
   stylesheet. KPI row stacks/wraps below desktop width. Charts resize to
   their container.
2. Pick ONE team-table mobile strategy (horizontal scroll container OR
   stacked/collapsed rows) and apply it consistently.
3. Collapse filter controls (project/tool/date-range) into a
   mobile-friendly control below tablet width.

═══════════════════════════════════════
STEP 2 — Verify
═══════════════════════════════════════

4. Using the browser's device toolbar, check the layout at 375px, 768px,
   1024px, and 1440px widths. Confirm no horizontal page overflow, no
   overlapping elements, and every filter/sort/chart interaction still
   works at each width.

Once implementation is complete and all tests pass, STOP. Do not stage,
commit, or push anything — confirm with the user first.

On user approval only:
  1. git add -A (stage all files).
  2. Commit via the commit-msg skill.
     Suggested title: "feat: platform PR-8 — responsive layout for mobile/tablet/desktop (T7)"
     Resolves: #112511
  3. git push -u origin feature/112511-responsive-layout-v3-pr8. No PR to open.

No Co-authored-by: Claude trailer.

PR 9 — BOLDVelocity branding: asset-generation prompts + integration (T8)

Branch: feature/112510-boldvelocity-branding-v3-pr9 Branches from: PR-8’s branch (wires assets into the final responsive shell) Model: Sonnet 5 Effort: low

Problem

The dashboard currently only carries the AlphaBOLD parent-brand logo (assets/alphabold-logo.png). “BOLDVelocity” (this dashboard’s own product identity) has no logo, favicon, or brand-asset set. This task’s deliverable is mostly the prompts needed to generate that identity with an image-generation tool, plus wiring the resulting files into the migrated, responsive shell once they exist.

Required change

Write docs/branding/boldvelocity-asset-prompts.md: a set of image-generation prompts for a BOLDVelocity wordmark/logo, a favicon (square, simplifies at 16×16/32×32), and any supporting asset (e.g. a social-share/OG image) — each prompt explicitly calls for the same visual language as the AlphaBOLD logo: warm off-white background, near-black text, gold #E3AD21/#CB9328 accent, Manrope-adjacent typography feel. Include a short rationale per prompt (why that composition/style) so a designer or another session can iterate without re-deriving the brief.
If an image-generation tool is available in-session, generate the assets and save them under assets/ (e.g. assets/boldvelocity-logo.png, assets/boldvelocity-favicon.ico/.svg). If not available, stop after step 1 and leave a clear note — do not ship a hand-drawn placeholder as if it were the real asset (Hard Rule 3 above).
Wire whichever assets exist into the migrated app shell: favicon link in the document head, logo reference in the top bar (alongside or replacing the AlphaBOLD logo placement — confirm with a stakeholder before removing the AlphaBOLD logo entirely; safest default is both logos side by side, AlphaBOLD as parent brand + BOLDVelocity as product brand).

Prompt — paste verbatim into Claude Code

You are implementing PR-9 of the Platform Modernization playbook
(docs/playbooks/v3-platform-modernization-playbook.md).

Read the full PR-9 section before writing any code. PR-7 (T9) and PR-8
(T7) must already be merged into this branch's base.

Branch: feature/112510-boldvelocity-branding-v3-pr9 from PR-8's branch.

Scope — T8 ONLY: brand-asset prompts + integration. Do not touch layout,
responsiveness, or data logic beyond adding the logo/favicon references.

═══════════════════════════════════════
STEP 1 — Prompts
═══════════════════════════════════════

1. WRITE docs/branding/boldvelocity-asset-prompts.md: image-generation
   prompts for a BOLDVelocity logo/wordmark, a favicon, and (optional) an
   OG/social-share image. Every prompt must explicitly specify the
   AlphaBOLD visual language: warm off-white background, near-black text,
   gold #E3AD21/#CB9328 accent, Manrope-adjacent typography. Include a
   one-line rationale per prompt.

═══════════════════════════════════════
STEP 2 — Generate (only if a tool is available this session)
═══════════════════════════════════════

2. If an image-generation tool is available, generate the assets and save
   under assets/ (boldvelocity-logo.png, boldvelocity-favicon.ico/.svg). If
   none is available, stop here — do not commit a placeholder logo/favicon
   in place of a real generated asset.

═══════════════════════════════════════
STEP 3 — Integration (only if assets exist)
═══════════════════════════════════════

3. Add the favicon link to the app shell's document head.
4. Add the BOLDVelocity logo to the top bar alongside the existing
   AlphaBOLD logo (do not remove the AlphaBOLD logo without confirming
   with a stakeholder first).
5. Verify at the breakpoints from PR-8 that both logos/the favicon render
   correctly and don't break the responsive top-bar layout.

Once implementation is complete and all tests pass, STOP. Do not stage,
commit, or push anything — confirm with the user first.

On user approval only:
  1. git add -A (stage all files).
  2. Commit via the commit-msg skill.
     Suggested title: "feat: platform PR-9 — BOLDVelocity branding prompts + asset integration (T8)"
     Resolves: #112510
  3. git push -u origin feature/112510-boldvelocity-branding-v3-pr9. No PR to open.

No Co-authored-by: Claude trailer.

5. Verification Samples

Checkpoint	Verify
PR-7 merged	Dashboard renders via the new framework’s dev server/build; every pre-migration filter/sort/chart interaction still works; `aggregate()`’s output shape is unchanged, `store/`/`api/`/`connectors/` untouched
PR-8 merged	Layout is usable with no horizontal overflow at 375px/768px/1024px/1440px; team table has a working mobile strategy; filters collapse to a mobile-friendly control below tablet width
PR-9 merged	`docs/branding/boldvelocity-asset-prompts.md` exists with AlphaBOLD-consistent prompts; if assets were generated, favicon + logo render correctly at every breakpoint from PR-8
Any PR	`Developer Productivity Dashboard.dc.html` and `support.js` untouched; no changes to `store/`, `api/`, or `connectors/`

6. Rollback

PR-7 (T9, framework migration): Revert to the prior static public/ shell (still intact on dev until this PR merges); no data-layer impact since this is rendering-only.
PR-8 (T7, responsive layout): Revert the added breakpoints/mobile styles; shell reverts to desktop-only layout, no functional regression.
PR-9 (T8, branding): Remove the BOLDVelocity asset files and their head/top-bar references; the AlphaBOLD logo alone remains, exactly as before this PR. The prompts doc can stay even if rolled back — it costs nothing kept around for future reference.

Platform Modernization — V3 Build-Out Playbook (T7 / T8 / T9)

Platform Modernization — V3 Build-Out Playbook (T7 / T8 / T9)

How to Use This Document

Framework choice — Next.js vs Vue

Framework/routing decision — DECIDED (2026-07-23)

1. Executive Summary

PR Strategy — 3 PRs, stacked T9 → T7 → T8

Merge Sequencing

Model Guidance

2. PR Plan

3. Files Touched

4. Hard Rules

PR 7 — Migrate public/ from static HTML/JS to Vue + Vite + vue-router (T9)

Problem

Required change

Prompt — paste verbatim into Claude Code

PR 8 — Responsive layout for all screen resolutions, including mobile (T7)

Problem

Required change

Prompt — paste verbatim into Claude Code

PR 9 — BOLDVelocity branding: asset-generation prompts + integration (T8)

Problem

Required change

Prompt — paste verbatim into Claude Code

5. Verification Samples

6. Rollback

PR 7 — Migrate `public/` from static HTML/JS to Vue + Vite + vue-router (T9)