Changelog

Guided tours of every report page. While a step plays, the page dims and the section being talked about is cut out and ringed, so the explanation and the thing being explained are never separated.

• Five tours — overview, people, blockers, capacity, stages and volume — listed on /tutorials with progress kept per tour.
• Steps target visuals by their PAGES.md reference, so a tour step and the handover document point at the same visual.
• Voice over uses the browser's own speech voice; the spoken text is the caption text, so they cannot drift.
• The popup carries play/pause, mute, a progress bar and an autoplay option that advances to the next step when the narration ends.
• A ▶ Tutorial button sits in the page tab strip under the canvas and starts the tour for the page you are on. Escape ends a tour; arrow keys step through it.
• Tutorials are project furniture, outside the 1280×720 canvas and outside the Power BI specification.

• /tutorials
• Page tab strip → ▶ Tutorial
• src/features/tutorials/

1. Open /tutorials and start the operational overview tour, or press ▶ Tutorial under any report page.
2. Watch the highlight move from the slicer strip to the bands, the trend, the breakdown and the attention strip.
3. Untick autoplay and confirm the tour waits for Next; tick it again and confirm it advances on its own.

Every change made to Platform 4 since the first build is now listed inside the instrument itself, grouped by day and collapsed until a date is opened.

• Each entry states the area, the scope, what changed, where it lives and how to test it.
• Days are collapsed by default; the badge on each day shows how many changes landed.
• The page sits outside the 1280×720 report canvas — it is project furniture, not a report page, and is not part of the Power BI specification.

• Statement page → Changelog
• /changelog

1. Open the statement page and follow the Changelog link.
2. Click a date to expand it and read the entries underneath.

The deliverable set that outlives the prototype: the build instruction a Power BI developer works from, opening with an honest statement of what this is, what is real and what is simulated.

• HANDOVER.md opens with 'What this prototype is and is not' and 'What is real and what is simulated' — the React code is explicitly not for reuse.
• MODEL.md, MEASURES.md, PAGES.md, TARGETS.md, RLS.md, FEASIBILITY.md and ACCESSIBILITY.md written as the transferable specification.
• A 23-line definition-of-done check reported pass by pass: 19 pass, 2 partial, 0 hard failures. The three open edges — the unbuilt cycle-time page, two matrices without a flat table view, and empty-state frames without alt text — are named rather than argued away.
• Every one of the fourteen tolerance bands is recorded as not ready to draw: eight have no owner at all, six have an owner but no agreed value.

• HANDOVER.md
• docs/reporting/

1. Read HANDOVER.md top to bottom; the definition-of-done table is the middle section.
2. Check the closing build order — theme first, model second, one tolerance band before fourteen.

Two artefacts that transfer directly into the built report: a complete theme file, and the answer to the behaviour actually being replaced — exporting to Excel and working on a stale copy.

• theme.json carries the full categorical palette, good/neutral/bad/minimum/center/maximum mapped to the diverging ramp, the Segoe UI text classes, and visualStyles defaults so every visual inherits square 1px borders, no shadow, horizontal gridlines only and white cards on a grey page.
• The file states which Power BI Desktop schema version it targets and notes that the developer should confirm against current Microsoft documentation before import.
• The overview page carries a permanent 'Analyze in Excel' explanation: Excel connects live to the model rather than downloading a snapshot, and the field list shows the same measures and folders as the report.
• The model was made good on that promise — measures in business language and sentence case across five display folders, every key, sync and audit column hidden, formatting set in the model rather than in the visual, and one marked date table with a business-friendly hierarchy.

• docs/brand/theme.json
• Overview page, bottom strip

1. Open the overview page and read the Analyze in Excel strip at the bottom.
2. Open docs/brand/theme.json and confirm it parses and names the schema version.

The three finishing pieces that are usually skipped: a separately authored phone layout, a table equivalent for every visual, and a deliberate contrast, greyscale, tab-order and print pass.

• A 320×640 mobile layout of the overview only — six tolerance bands stacked full width, then the attention strip as a list, and nothing else.
• Every page has a table-view bookmark; charts and tolerance bands switch to their tabular equivalent.
• The palette was retuned into a greyscale ladder so all text clears 4.5:1 and every graphic clears 3:1; ramp steps were darkened until conditional-format fills passed with black text.
• Redundant encoding added where colour alone was not enough — direct labels on any chart with four or fewer series, ▲/▽ glyphs on diverging fills, and hatch patterns for print.
• Tab order declared explicitly on every page, and alt text on every visual describing what it shows rather than what it is.
• A4 landscape print verified in greyscale with the as-at stamp intact; the capacity grid and blocker table were the priority cases.

• /overview-mobile
• Every page → table view toggle
• docs/reporting/ACCESSIBILITY.md

1. Open /overview-mobile and confirm only bands and the attention list are present.
2. Toggle table view on any page and confirm each chart becomes a table.
3. Print any page to PDF in greyscale and check the as-at stamp survives.

The pages reached by drilling rather than by navigation, which answer 'which one, and what do I do'.

• Project detail: header identity strip, gate history as planned versus actual, open actions, team over eight weeks, and the last twenty events.
• Restricted projects state plainly that detail requires clearance while leaving metadata visible — the restriction is legible rather than a blank page.
• Person detail: twelve-week allocation, projects assigned, open actions and gates owned, with expiring clearances rendered in the adverse ramp and labelled 'Expiring'.
• Four 320×240 tooltip pages: stage, person's next four weeks, five oldest overdue actions, and the projects behind a capacity cell.
• Drillthroughs carry an as-at stamp, no slicer strip, and a 9pt footnote naming the filters carried in.

• /project-detail
• /person-detail
• Tooltip pages T1–T4

1. Click any project name on the overview attention strip to drill through.
2. Open a restricted project and confirm the clearance statement replaces the detail body.
3. Hover a capacity grid cell to see the tooltip page.

Where is capacity, and where are we over-committed — forward, never retrospective.

• Four tolerance bands, one per iHub plus global, sharing one fixed scale so the hubs can be read against each other.
• The capacity grid: resource by week over twelve weeks, diverging heat-map, with glyphs so it survives greyscale and print.
• Capacity by skill as a horizontal bar, which is what makes a bottleneck visible.
• Unallocated capacity as a twelve-week column chart split by iHub.
• Engineering competencies were added to the model to support the skill view, and planned hours now track available hours through seasonal absence.

• /capacity

1. Open /capacity and confirm all four bands read on the same scale.
2. Hover a grid cell to see which projects sit behind it, and click through to the person.

What is blocked, by what, and how long work is actually taking — one row per active cause, not one row per project.

• The blocker table groups by cause and sorts oldest first: overdue action, gate stalled, approval unresolved, awaiting customer, awaiting partner, resource unavailable, no activity.
• Waiting on a customer and waiting on a partner are separated, because they are different conversations with different people.
• Overdue actions by owner, split by age band, with a tooltip listing that owner's five oldest.
• Cycle time as a histogram with a median rule and a target band, and on-time gate rate as a trend line.
• A footnote records that the escalation policy for unresolved approvals has not been set.

• /blockers

1. Open /blockers and read down the blocker table; the oldest item in each cause group is at the top.
2. Hover an owner bar to see their five oldest actions.