konpeki 0.3.0 → 0.4.0

package/slides/README.md

@@ -1,153 +0,0 @@
-# Decks and examples
-
-The image gallery below is for the repository checkout. The npm package includes
-editable examples and prompts but omits gallery PNGs; view this page and its
-screenshots in the repository, or render the source locally.
-
-## Introducing Konpeki
-
-[Introducing Konpeki](introducing-konpeki/README.md) is a six-slide factual product
-introduction authored in the shared canvas's editable composition format.
-Open `?example=introducing-konpeki` in the running application, or download
-its [composition JSON](introducing-konpeki/composition.json) and use **Open**.
-
-## Retained drawing references
-
-Each retained example contains its approved `PROMPT.md`, editable `index.tsx`, and final
-PNGs in `screenshots/`. Generation logs, environment records, review reports and
-superseded captures are not included. Subjects and datasets in these retained
-references are fictional; they are not another presentation runtime.
-
-## Representative charts
-
-### Line chart — Tide, page 1
-
-Two time series on a shared scale, direct labels, a target line, an event marker
-and an explicit gap for missing data. [Editable source](line-chart/index.tsx).
-
-![Line chart with a target and missing-data gap](line-chart/screenshots/page-1.png)
-
-### Grouped bar chart — Birch, page 1
-
-Horizontal before/after bars with a shared zero baseline and direct values.
-[Editable source](bar-chart/index.tsx).
-
-![Grouped horizontal before-and-after bars](bar-chart/screenshots/page-1.png)
-
-### Vertical bar chart — Fieldnote, page 1
-
-Zero-based columns compare processing throughput with direct values.
-[Editable source](vertical-bar-charts/index.tsx).
-
-![Vertical bars comparing indexing throughput](vertical-bar-charts/screenshots/page-1.png)
-
-### Two charts side by side — Fieldnote, page 2
-
-Throughput on the left and visibility delay on the right show the trade-off,
-with separate units, zero-based scales and acceptance thresholds.
-[Editable source](vertical-bar-charts/index.tsx).
-
-![Side-by-side throughput and visibility-delay bar charts](vertical-bar-charts/screenshots/page-2.png)
-
-### Stacked bar chart — Fern, page 1
-
-Direct-count segments compare completion before and after a hint, with the same
-denominator for every task. [Editable source](research-brief/index.tsx).
-
-![Stacked bars showing task completion counts](research-brief/screenshots/page-1.png)
-
-## Representative content layouts
-
-### Two columns — Fern, page 2
-
-Parallel columns separate observed evidence from researchers' interpretations.
-[Editable source](research-brief/index.tsx).
-
-![Two-column observations and interpretations](research-brief/screenshots/page-2.png)
-
-### Three columns — Lantern, page 2
-
-Three aligned time-based columns distinguish rollback, partial recovery and
-backlog clearance. [Editable source](incident-workflow/index.tsx).
-
-![Three-column incident recovery stages](incident-workflow/screenshots/page-2.png)
-
-### Main panel and sidebar — Patchnote, page 2
-
-A large illustrative draft panel pairs with a narrower human-review checklist.
-[Editable source](product-introduction/index.tsx).
-
-![Draft interface with a review sidebar](product-introduction/screenshots/page-2.png)
-
-## Representative diagrams and structured information
-
-### Architecture diagram — Parcel Relay, page 1
-
-Named components and attached connectors explain acceptance and delivery.
-[Editable source](architecture/index.tsx).
-
-![Event acceptance and delivery architecture](architecture/screenshots/page-1.png)
-
-### Sequence diagram — Parcel Relay, page 3
-
-Two participant lifelines show a lost response and retry of the same event.
-[Editable source](architecture/index.tsx).
-
-![Timeout and retry sequence diagram](architecture/screenshots/page-3.png)
-
-### Gantt chart — Harbor, page 1
-
-A shared calendar axis compares baseline, completed and forecast work, with
-dependencies and release gates. [Editable source](delivery-plan/index.tsx).
-
-![Gantt chart with dependencies and gates](delivery-plan/screenshots/page-1.png)
-
-### Sankey chart — Brook, page 1
-
-Proportional flows carry 120 tickets from intake through handling to outcomes,
-with direct counts and conservation at each stage.
-[Editable source](sankey/index.tsx).
-
-![Sankey chart of support ticket routing and outcomes](sankey/screenshots/page-1.png)
-
-### Evidence table — Harbor, page 2
-
-Aligned stage–evidence rows use horizontal rules to make gate requirements easy
-to compare. [Editable source](delivery-plan/index.tsx).
-
-![Stage and evidence requirements table](delivery-plan/screenshots/page-2.png)
-
-## All examples
-
-The selections above demonstrate distinct visual patterns rather than ranking
-decks. All final screenshots remain available below.
-
-| Example | Prompt | Final screenshots |
-| --- | --- | --- |
-| Patchnote — product introduction | [Prompt](product-introduction/PROMPT.md) | [Images](product-introduction/screenshots/) |
-| Parcel Relay — architecture | [Prompt](architecture/PROMPT.md) | [Images](architecture/screenshots/) |
-| Fieldnote — experiment | [Prompt](experiment/PROMPT.md) | [Images](experiment/screenshots/) |
-| Lantern — incident workflow | [Prompt](incident-workflow/PROMPT.md) | [Images](incident-workflow/screenshots/) |
-| Moss — comparison | [Prompt](comparison/PROMPT.md) | [Images](comparison/screenshots/) |
-| Juniper — migration | [Prompt](migration/PROMPT.md) | [Images](migration/screenshots/) |
-| Clearpath — OG images | [Prompt](og-images/PROMPT.md) | [Images](og-images/screenshots/) |
-| Alder — article briefing | [Prompt](article-brief/PROMPT.md) | [Images](article-brief/screenshots/) |
-| Waymark — results explanation | [Prompt](results-explanation/PROMPT.md) | [Images](results-explanation/screenshots/) |
-| Dockline — retrospective | [Prompt](retrospective/PROMPT.md) | [Images](retrospective/screenshots/) |
-| Fern — research briefing | [Prompt](research-brief/PROMPT.md) | [Images](research-brief/screenshots/) |
-| Cedar Support — decision memo | [Prompt](decision-memo/PROMPT.md) | [Images](decision-memo/screenshots/) |
-| Harbor — delivery plan | [Prompt](delivery-plan/PROMPT.md) | [Images](delivery-plan/screenshots/) |
-| Folio — teaching | [Prompt](teaching/PROMPT.md) | [Images](teaching/screenshots/) |
-| Tide — line chart | [Prompt](line-chart/PROMPT.md) | [Images](line-chart/screenshots/) |
-| Birch — bar chart | [Prompt](bar-chart/PROMPT.md) | [Images](bar-chart/screenshots/) |
-| Fieldnote — vertical and paired bar charts | [Prompt](vertical-bar-charts/PROMPT.md) | [Images](vertical-bar-charts/screenshots/) |
-| Brook — Sankey chart | [Prompt](sankey/PROMPT.md) | [Images](sankey/screenshots/) |
-
-The `index.tsx` files are retained presentation-runtime-independent React/SVG
-drawing references, not runnable routes or a second deck format. Agents can
-inspect and adapt their techniques, then convert supported SVG primitives into
-editable vector elements in the owning composition component.
-Shared authoring resources live in `design/` and `lib/`.
-
-Screenshots reflect the final reviewed browser renders, including manual repairs.
-They do not establish PDF/PPTX, cross-browser or cross-application fidelity.

package/slides/architecture/PROMPT.md

@@ -1,31 +0,0 @@
-Make a three-page presentation explaining Parcel Relay to engineers joining its
-team. Help them follow an event from acceptance to delivery and understand why
-a timeout can lead to a duplicate request.
-
----
-
-Parcel Relay is a fictional webhook delivery service. A producer submits an
-event with an event ID. The API saves the event and its delivery job in one
-database transaction and returns Accepted after the transaction commits. If
-the transaction cannot commit, the API returns an error and the event has not
-been accepted.
-
-Workers claim jobs from that database using time-limited leases, then POST the
-events to customer endpoints. Each request includes the event ID. The database
-holds the job queue; there is no separate message broker.
-
-A 2xx response marks the job delivered. A timeout or 5xx schedules another
-attempt, up to three attempts in total. A third unsuccessful attempt marks the
-job failed for human investigation. A 4xx is terminal in this example. If a
-worker crashes, another worker can claim its unfinished job after the lease
-expires, even if the customer already received the earlier request.
-
-Customers must handle repeated event IDs. Relay cannot make their side effects
-atomic or guarantee exactly-once delivery.
-
----
-
-Walk through this failure: evt-204 reaches the customer, which applies its
-update, but the response is lost. Relay times out and retries evt-204. The
-customer recognizes the event ID and skips the repeated update. That final
-step depends on the customer's implementation; Relay does not enforce it.

package/slides/architecture/index.tsx

@@ -1,102 +0,0 @@
-import type { ReactNode } from 'react';
-import '../../lib/typeface.ts';
-
-const ink = '#172633', muted = '#4D5D6B', accent = '#006EAC', line = '#A7B2BC';
-function Text({ x, y, children, size = 34, weight = 400, color = ink }: { x: number; y: number; children: ReactNode; size?: number; weight?: number; color?: string }) {
-  return <text x={x} y={y} fontSize={size} fontWeight={weight} fill={color}>{children}</text>;
-}
-function Arrow({ x1, x2, y, dashed = false }: { x1: number; x2: number; y: number; dashed?: boolean }) {
-  const d = x2 > x1 ? -16 : 16;
-  return <g fill="none" stroke={accent} strokeWidth={3}><path d={`M${x1} ${y} H${x2}`} strokeDasharray={dashed ? '10 8' : undefined}/><path d={`M${x2 + d} ${y - 10} L${x2} ${y} L${x2 + d} ${y + 10}`}/></g>;
-}
-function Frame({ title, description, page, children }: { title: string; description: string; page: number; children: ReactNode }) {
-  return <svg xmlns="http://www.w3.org/2000/svg" width="1920" height="1080" viewBox="0 0 1920 1080" fontFamily="IBM Plex Sans, sans-serif" role="img" aria-label={`${title}. ${description}`}>
-    <rect width={1920} height={1080} fill="#FFFFFF"/>
-    <Text x={112} y={150} size={64} weight={600}>{title}</Text>
-    {children}
-    <Text x={1760} y={1018} size={26} color={muted}>{page} / 3</Text>
-  </svg>;
-}
-function Acceptance() {
-  return <Frame page={1} title="Parcel Relay accepts an event after commit" description="Fictional service. Producer submits an event ID to the API. The API saves event and job in one database transaction. Accepted follows commit; commit failure returns an error, so the event was not accepted. Workers claim leased jobs from the database and POST to customer endpoints with the event ID. No separate broker.">
-    <Text x={112} y={224} color={muted}>A fictional webhook service • the database holds both events and the job queue</Text>
-    <Text x={160} y={365} size={40} weight={600}>Producer</Text>
-    <Text x={548} y={365} size={40} weight={600}>API</Text>
-    <path d="M250 390 V635 M580 390 V635" fill="none" stroke={line} strokeWidth={2}/>
-    <rect x={965} y={294} width={835} height={280} rx={8} fill="#FFFFFF" stroke={line} strokeWidth={2}/>
-    <Text x={1005} y={355} size={40} weight={600}>Database</Text>
-    <Text x={1005} y={423}>Event + delivery job</Text>
-    <Text x={1005} y={479} color={accent} weight={500}>Saved in one transaction</Text>
-    <Text x={1005} y={531} size={30} color={muted}>Commit is the acceptance boundary.</Text>
-    <Arrow x1={250} x2={580} y={415}/>
-    <Text x={280} y={397} size={30}>Submit event ID</Text>
-    <Arrow x1={580} x2={965} y={415}/>
-    <Text x={690} y={391} size={30}>Save both</Text>
-    <Arrow x1={965} x2={580} y={515}/>
-    <Text x={680} y={563} size={30}>Commit succeeds</Text>
-    <Arrow x1={580} x2={250} y={610}/>
-    <Text x={236} y={660} color={accent} weight={500}>Return Accepted</Text>
-    <path d="M1120 704 V574 M1110 590 L1120 574 L1130 590" fill="none" stroke={accent} strokeWidth={3}/>
-    <Text x={1160} y={644} size={30}>Claim leased job</Text>
-    <Text x={112} y={797} size={40} weight={600}>If commit fails</Text>
-    <Text x={112} y={855}>API returns an error.</Text>
-    <Text x={112} y={907}>The event has not been accepted.</Text>
-    <Text x={1020} y={738} size={40} weight={600}>Worker</Text>
-    <path d="M1120 756 V844" fill="none" stroke={accent} strokeWidth={3}/>
-    <Arrow x1={1120} x2={1550} y={844}/>
-    <Text x={1160} y={891} size={30}>POST + event ID</Text>
-    <Text x={1555} y={817} size={38} weight={600}>Customer</Text>
-    <Text x={1555} y={869} size={30}>endpoint</Text>
-  </Frame>;
-}
-function Outcomes() {
-  return <Frame page={2} title="The response decides the job’s next state" description="2xx marks delivered. Timeout or 5xx schedules another attempt, up to three attempts total. The third unsuccessful attempt marks failed for human investigation. 4xx is terminal. If a worker crashes, another may claim the unfinished job after lease expiry even if the customer already received it.">
-    <Text x={112} y={228} color={muted}>After each POST, the worker records the outcome in the database.</Text>
-    <Text x={112} y={346} size={30} color={muted}>OBSERVED RESULT</Text>
-    <Text x={660} y={346} size={30} color={muted}>WHAT RELAY DOES</Text>
-    {[380, 490, 660, 780].map(y => <line key={y} x1={112} x2={1808} y1={y} y2={y} stroke={line} strokeWidth={2}/>)}
-    <Text x={112} y={447} size={40} weight={600}>2xx</Text>
-    <Text x={660} y={447} size={38}>Marks the job delivered.</Text>
-    <Text x={112} y={555} size={40} weight={600}>Timeout or 5xx</Text>
-    <Text x={660} y={552} size={38}>Schedules another attempt; three attempts total.</Text>
-    <Text x={660} y={609} size={32} color={muted}>Third unsuccessful attempt: failed, for human investigation.</Text>
-    <Text x={112} y={731} size={40} weight={600}>4xx</Text>
-    <Text x={660} y={731} size={38}>Terminal in this example.</Text>
-    <Text x={112} y={865} size={38} weight={600}>A worker crash can also repeat a request</Text>
-    <Text x={112} y={925} size={34}>After lease expiry, another worker can claim the unfinished job,</Text>
-    <Text x={112} y={975} size={34}>even if the customer already received the earlier request.</Text>
-  </Frame>;
-}
-function Duplicate() {
-  return <Frame page={3} title="A timeout can hide a completed update" description="evt-204 reaches the customer and applies its update, but the response is lost. Relay times out and retries the same event ID. The customer recognizes evt-204 and skips the repeated update. This deduplication depends on the customer implementation. Relay cannot enforce it, make customer side effects atomic, or guarantee exactly-once delivery.">
-    <Text x={112} y={224} color={muted}>The same event ID connects both requests: evt-204.</Text>
-    <Text x={260} y={334} size={40} weight={600}>Relay worker</Text>
-    <Text x={1130} y={334} size={40} weight={600}>Customer endpoint</Text>
-    <line x1={380} x2={380} y1={367} y2={785} stroke={line} strokeWidth={2}/>
-    <line x1={1260} x2={1260} y1={367} y2={785} stroke={line} strokeWidth={2}/>
-    <Arrow x1={380} x2={1260} y={432}/>
-    <Text x={610} y={406} size={32}>POST evt-204</Text>
-    <Text x={1310} y={445} size={34} weight={500}>Applies update</Text>
-    <path d="M1260 525 H760" fill="none" stroke={accent} strokeWidth={3} strokeDasharray="10 8"/>
-    <path d="M746 511 L774 539 M774 511 L746 539" stroke={accent} strokeWidth={3}/>
-    <Text x={835} y={504} size={32}>Response lost</Text>
-    <Text x={112} y={561} size={32}>Times out</Text>
-    <Text x={112} y={603} size={30} color={muted}>Outcome unknown</Text>
-    <Arrow x1={380} x2={1260} y={663}/>
-    <Text x={610} y={637} size={32}>Retry POST evt-204</Text>
-    <Text x={1310} y={672} size={34} weight={500}>Recognizes evt-204</Text>
-    <Text x={1310} y={720} size={34} color={accent} weight={500}>Skips repeated update</Text>
-    <Text x={112} y={861} size={40} weight={600}>Customers must handle repeated event IDs.</Text>
-    <Text x={112} y={924} size={34}>The skip above depends on customer code; Relay does not enforce it.</Text>
-    <Text x={112} y={974} size={34}>Relay cannot make customer side effects atomic or guarantee exactly-once delivery.</Text>
-  </Frame>;
-}
-
-export const meta = { title: 'Parcel Relay', createdAt: '2026-09-12T14:14:00Z' };
-export const notes = [
-  'Audience question: When is an event accepted, and where does the job live? The connector from the database to the worker denotes job ownership, not a separate message broker.',
-  'Audience question: What happens after a delivery attempt, or a worker crash? No backoff duration or lease duration is specified by the fictional brief.',
-  'Audience question: Why did evt-204 repeat, and who prevents duplicate side effects? The customer deduplication outcome is an example, not a guarantee supplied by Relay.',
-];
-const pages = [Acceptance, Outcomes, Duplicate];
-export default pages;

package/slides/article-brief/PROMPT.md

@@ -1,35 +0,0 @@
-Turn the article below into a two-page briefing for engineering managers.
-Explain its main argument and a practical way to apply it without turning
-the author's experience into a universal rule.
-
----
-
-This is the complete fictional article, written for this example.
-
-“The decision record that survived the meeting”
-By Mira Sol, an engineer at the fictional company Alder
-
-Our meeting notes were detailed, but a month later we could not explain why
-we had chosen a daily data export over a live integration. The notes recorded
-who spoke and which tasks followed. They did not record the constraint that
-made the decision sensible: the receiving system accepted only one upload
-per day.
-
-We started keeping a short decision record alongside the work. It contains
-the question, the constraints known at the time, the alternatives considered,
-the choice and the condition that would make us revisit it. For the export,
-that condition was the receiving system adding a supported live API.
-
-This is not an attempt to predict every future requirement. It gives the next
-engineer enough context to distinguish a deliberate trade-off from an accident.
-When circumstances change, we append a new decision and link the old one
-rather than silently rewriting its rationale.
-
-Not every implementation detail deserves a record. We use one when a choice
-crosses team boundaries, is costly to reverse or depends on a constraint likely
-to change. Routine local choices can stay in code review. We still need task
-lists and meeting notes; they answer different questions.
-
-We have not measured whether this practice makes delivery faster. Our claim
-is narrower: recording the reason and revisit condition makes our decisions
-easier to explain later.

package/slides/article-brief/index.tsx

@@ -1,71 +0,0 @@
-import type { ReactNode } from 'react';
-import { Text } from '../../lib/text.tsx';
-import { fontsReady } from '../../lib/typeface.ts';
-
-await fontsReady;
-
-const ink = '#182B35';
-const muted = '#4C606B';
-const accent = '#006D77';
-
-function Copy({ x = 112, y, width = 1696, size = 38, weight = 400, color = ink, children }: {
-  x?: number; y: number; width?: number; size?: number; weight?: number; color?: string; children: string;
-}) {
-  return <Text x={x} y={y} width={width} size={size} weight={weight} color={color} maxLines={8} leading={1.22}>{children}</Text>;
-}
-
-function Canvas({ page, title, description, children }: { page: number; title: string; description: string; children: ReactNode }) {
-  return <svg xmlns="http://www.w3.org/2000/svg" width="1920" height="1080" viewBox="0 0 1920 1080" role="img"
-    aria-labelledby={`title-${page} description-${page}`} data-page={page} fontFamily="IBM Plex Sans">
-    <title id={`title-${page}`}>{title}</title>
-    <desc id={`description-${page}`}>{description}</desc>
-    <rect width="1920" height="1080" fill="#FFFFFF" />
-    <Copy y={146} size={72} weight={600}>{title}</Copy>
-    {children}
-    <text x="1808" y="1020" textAnchor="end" fill={muted} fontSize="28">{page} / 2</text>
-  </svg>;
-}
-
-const Argument = () => <Canvas page={1} title="Keep the reason with the decision"
-  description="In Mira Sol’s fictional Alder account, meeting notes preserved speakers and tasks but lost why a daily export was chosen. The receiving system allowed only one upload per day. Alder’s decision record preserved that constraint and a revisit trigger: a supported live API. Sol claims decisions became easier to explain, not measured faster delivery.">
-  <Copy y={224} size={32} color={muted}>Mira Sol’s “The decision record that survived the meeting” · A fictional Alder account</Copy>
-  <Copy y={354} width={560} size={48} weight={600}>A month later, the “why” was missing.</Copy>
-  <Copy y={508} width={550} color={muted}>Meeting notes captured who spoke and what to do next. They lost the constraint behind the export choice.</Copy>
-  <Copy x={800} y={350} width={1008} size={30} weight={600} color={accent}>ALDER’S EXPORT DECISION</Copy>
-  <line x1="800" x2="1808" y1="388" y2="388" stroke="#A5B4BC" strokeWidth="2" />
-  <Copy x={800} y={450} width={260} size={34} weight={600}>Choice</Copy>
-  <Copy x={1100} y={450} width={708} size={38}>Daily data export over a live integration</Copy>
-  <line x1="800" x2="1808" y1="532" y2="532" stroke="#A5B4BC" strokeWidth="2" />
-  <Copy x={800} y={594} width={260} size={34} weight={600}>Reason</Copy>
-  <Copy x={1100} y={594} width={708} size={38}>Receiving system accepted only one upload per day</Copy>
-  <line x1="800" x2="1808" y1="676" y2="676" stroke="#A5B4BC" strokeWidth="2" />
-  <Copy x={800} y={738} width={260} size={34} weight={600}>Revisit when</Copy>
-  <Copy x={1100} y={738} width={708} size={38}>Receiving system adds a supported live API</Copy>
-  <line x1="800" x2="1808" y1="820" y2="820" stroke="#A5B4BC" strokeWidth="2" />
-  <Copy y={922} size={40} weight={500} color={accent}>The claim: decisions became easier to explain later.</Copy>
-  <Copy y={975} size={32} color={muted}>Sol reports no measurement of faster delivery; this is one team’s experience.</Copy>
-</Canvas>;
-
-const Application = () => <Canvas page={2} title="Try a record on one consequential choice"
-  description="Suggested application for engineering managers, adapted from Sol’s fictional account: choose a decision that crosses teams, is costly to reverse, or rests on a changing constraint. Keep a short record beside the work with question, constraints, alternatives, choice, and revisit condition. If Alder gains a supported live API, reassess the export; append and link a new decision rather than overwrite the old rationale. Routine local choices can stay in code review. Keep task lists and meeting notes for their separate purposes.">
-  <Copy y={224} size={32} color={muted}>A suggested first trial, adapted from Sol’s practice—not a requirement for every team.</Copy>
-  <Copy y={350} width={620} size={44} weight={600}>Choose selectively</Copy>
-  <Copy y={420} width={620} size={36}>Use a record when a choice:</Copy>
-  <Copy y={490} width={620} size={38}>• Crosses team boundaries</Copy>
-  <Copy y={552} width={620} size={38}>• Is costly to reverse</Copy>
-  <Copy y={614} width={620} size={38}>• Relies on a constraint likely to change</Copy>
-  <Copy y={780} width={610} size={34} color={muted}>Routine local choices can stay in code review. Keep task lists and meeting notes; they answer different questions.</Copy>
-  <Copy x={860} y={350} width={948} size={44} weight={600}>Keep a short record beside the work</Copy>
-  <Copy x={860} y={423} width={948} size={36}>Question · Known constraints · Alternatives</Copy>
-  <Copy x={860} y={477} width={948} size={36}>Choice · Condition for revisiting</Copy>
-  <Copy x={860} y={600} width={948} size={44} weight={600} color={accent}>When Alder gains a supported live API…</Copy>
-  <Copy x={860} y={723} width={948} size={38}>Reassess whether the daily export still fits. Append a new decision and link the old one; preserve the original rationale.</Copy>
-  <Copy x={860} y={911} width={948} size={34} color={muted}>A manager’s review question: can the next engineer explain the trade-off and when to reconsider it?</Copy>
-</Canvas>;
-
-export const meta = { title: 'Alder — The reason behind the decision' };
-export const notes = [
-  'Source: the complete fictional article in PROMPT.md by Mira Sol at Alder. This page summarizes the stated experience and preserves its explicit evidence limit.',
-  'The single-choice trial and manager’s review question are editorial applications, not quotations or measured outcomes. All five record fields and selective-use criteria come from the supplied article.',
-];
-export default [Argument, Application];

package/slides/bar-chart/PROMPT.md

@@ -1,39 +0,0 @@
-Make a two-page briefing for the operations lead at Birch about processing time
-across five workflows. Use grouped horizontal bars to compare before and after,
-then explain the decision the evidence supports and what remains unknown.
-
-Use one common zero-based minute axis, directly label every bar and keep the
-before/after series order consistent. Make the workflow that became slower as
-easy to notice as the improvements.
-
----
-
-Birch is a fictional internal operations team. These are synthetic, hand-authored
-median active processing times per completed case. Waiting time is excluded.
-Each workflow has 80 completed cases in the before period and 80 different
-completed cases in the after period. Lower is better.
-
-Workflow | Before median (minutes) | After median (minutes)
-Account setup | 18 | 12
-Address correction | 11 | 10
-Refund review | 25 | 19
-Access removal | 7 | 8
-Supplier onboarding | 32 | 24
-
-The before and after periods each lasted two weeks. A revised work queue was
-introduced between them. Cases were not randomized or matched, and case
-complexity and staffing could differ. These are independent groups, not paired
-measurements of the same cases. No raw times, variability estimates or quality
-measurements are supplied.
-
----
-
-Four workflows have lower observed medians; access removal rises from 7 to 8
-minutes. Supplier onboarding has the largest absolute median reduction, eight
-minutes, but still has the highest after-period median at 24 minutes.
-
-Recommend investigating the access-removal increase and checking case mix and
-quality before extending the revised queue. The data do not establish that the
-queue caused any change. Do not multiply median differences by case counts to
-claim total time or money saved, or imply that a lower median means every case
-became faster.

package/slides/bar-chart/index.tsx

@@ -1,97 +0,0 @@
-import type { ReactNode } from 'react';
-import { Bar } from '@nivo/bar';
-import '../../lib/typeface.ts';
-import { chartDefaults } from '../../lib/charts.ts';
-import { palettes } from '../../lib/taste.ts';
-
-const ink = '#182B36';
-const muted = '#445663';
-const before = '#536879';
-const after = '#146B60';
-export const workflows = [
-  { workflow: 'Account setup', Before: 18, After: 12 },
-  { workflow: 'Address correction', Before: 11, After: 10 },
-  { workflow: 'Refund review', Before: 25, After: 19 },
-  { workflow: 'Access removal', Before: 7, After: 8 },
-  { workflow: 'Supplier onboarding', Before: 32, After: 24 },
-];
-
-function Copy({ x = 112, y, size = 32, weight = 400, fill = ink, children }: {
-  x?: number; y: number; size?: number; weight?: number; fill?: string; children: ReactNode;
-}) {
-  return <text x={x} y={y} fontSize={size} fontWeight={weight} fill={fill}>{children}</text>;
-}
-
-function Canvas({ title, description, page, children }: {
-  title: string; description: string; page: number; children: ReactNode;
-}) {
-  return <svg xmlns="http://www.w3.org/2000/svg" width="1920" height="1080" viewBox="0 0 1920 1080"
-    role="img" aria-label={`${title}. ${description}`} fontFamily="IBM Plex Sans, sans-serif" data-birch-page={page}>
-    <rect width="1920" height="1080" fill="#FFFFFF" />
-    <Copy y={136} size={62} weight={600}>{title}</Copy>
-    {children}
-    <Copy x={1770} y={1020} size={24} fill={muted}>{page} / 2</Copy>
-  </svg>;
-}
-
-const Evidence = () => <Canvas page={1} title="Four medians fell; access removal rose"
-  description="Synthetic Birch data, median active processing minutes per completed case; lower is better. Account setup: before 18, after 12. Address correction: before 11, after 10. Refund review: before 25, after 19. Access removal: before 7, after 8. Supplier onboarding: before 32, after 24. Each workflow has 80 independent cases per period. Waiting time excluded. These observations do not establish causation.">
-  <Copy y={202} size={30} fill={muted}>Birch · Synthetic median active processing time per completed case · Lower is better</Copy>
-  <g transform="translate(112 262)">
-    <Bar {...chartDefaults(palettes.paper)} width={1696} height={640}
-      data={[...workflows].reverse()} keys={['Before', 'After']} indexBy="workflow"
-      layout="horizontal" groupMode="grouped" valueScale={{ type: 'linear', min: 0, max: 35 }}
-      margin={{ top: 0, right: 90, bottom: 60, left: 345 }} padding={0.26} innerPadding={7}
-      colors={({ id }) => id === 'Before' ? before : after}
-      label={d => `${d.id}  ${d.value}`} labelTextColor="#FFFFFF" labelSkipWidth={0} labelSkipHeight={0}
-      axisLeft={{ tickSize: 0, tickPadding: 24 }}
-      axisBottom={{ tickSize: 0, tickPadding: 16, tickValues: [0, 5, 10, 15, 20, 25, 30, 35] }}
-      enableGridX enableGridY={false} gridXValues={[0, 5, 10, 15, 20, 25, 30, 35]}
-      theme={{ text: { fontFamily: 'IBM Plex Sans', fontSize: 28, fill: ink },
-        axis: { ticks: { text: { fontSize: 28, fill: ink } }, domain: { line: { stroke: '#8A969F' } } },
-        grid: { line: { stroke: '#DCE2E5', strokeWidth: 1 } },
-        labels: { text: { fontSize: 26, fontWeight: 500 } } }}
-    />
-  </g>
-  <Copy x={1340} y={935} size={27} fill={muted}>Minutes · common zero baseline</Copy>
-  <Copy y={934} size={30} weight={600} fill={after}>Access removal: +1 minute</Copy>
-  <Copy y={984} size={27} fill={muted}>80 different cases per workflow per period · Two weeks each · Waiting time excluded</Copy>
-</Canvas>;
-
-const Decision = () => <Canvas page={2} title="Investigate before extending the revised queue"
-  description="Recommendation: investigate the access-removal increase and check case mix and quality before extending the revised queue. Supplier onboarding has the largest absolute median reduction, 8 minutes, but still the highest after median, 24 minutes. Independent groups were not randomized or matched; complexity and staffing could differ. No raw times, variability or quality measurements were supplied. Median differences cannot establish total savings or imply every case became faster.">
-  <Copy y={207} size={32} fill={muted}>Observed changes are a reason to investigate, not evidence that the queue caused them.</Copy>
-  <Copy y={322} size={38} weight={600}>Check before rollout</Copy>
-  <Copy x={1050} y={322} size={38} weight={600}>What the comparison cannot tell us</Copy>
-
-  <Copy y={400} size={32} weight={600} fill={after}>Investigate access removal</Copy>
-  <Copy y={451}>Its median rose from 7 to 8 minutes.</Copy>
-  <Copy y={497}>Review the workflow and the cases behind it.</Copy>
-
-  <Copy y={594} size={32} weight={600} fill={after}>Check case mix, staffing and quality</Copy>
-  <Copy y={645}>Before extending the queue, compare complexity</Copy>
-  <Copy y={691}>and staffing, and collect quality measurements.</Copy>
-
-  <Copy y={788} size={32} weight={600} fill={after}>Keep supplier onboarding in view</Copy>
-  <Copy y={839}>32 → 24 minutes: the largest drop, 8 minutes.</Copy>
-  <Copy y={885}>It still has the highest after-period median.</Copy>
-
-  <Copy x={1050} y={400} size={32} weight={600}>No causal attribution</Copy>
-  <Copy x={1050} y={451}>The queue changed between two two-week periods.</Copy>
-  <Copy x={1050} y={497}>Groups were independent, not randomized or matched;</Copy>
-  <Copy x={1050} y={543}>case complexity and staffing could differ.</Copy>
-
-  <Copy x={1050} y={640} size={32} weight={600}>No estimate of uncertainty or total savings</Copy>
-  <Copy x={1050} y={691}>No raw times, variability or quality data were supplied.</Copy>
-  <Copy x={1050} y={737}>Do not multiply median changes by case counts</Copy>
-  <Copy x={1050} y={783}>to claim total time or money saved.</Copy>
-  <Copy x={1050} y={861}>A lower median does not mean every case was faster.</Copy>
-  <Copy y={1000} size={27} fill={muted}>Birch is fictional. All measurements are synthetic, hand-authored data.</Copy>
-</Canvas>;
-
-export const meta = { title: 'Birch — Processing time' };
-export const notes = [
-  'Source: exact supplied PROMPT.md. The chart compares independent medians, not paired cases. All bars share a 0–35 minute scale.',
-  'Recommendation follows the supplied brief. No causal, total-savings, statistical-significance or universal-improvement claim is justified.',
-];
-export default [Evidence, Decision];

package/slides/comparison/PROMPT.md

@@ -1,29 +0,0 @@
-Make a three-page presentation helping the operations lead at Moss choose a
-support inbox for a six-person team. Compare the options against the team's
-actual needs and recommend what to trial.
-
----
-
-Moss and all three products are fictional. The team needs email intake, shared
-assignment and a complete CSV export of ticket history. Its monthly subscription
-budget is $150. Chat support would be useful later, but is not required now.
-The team does not have capacity to operate its own server.
-
-- Postbox: hosted, $18 per agent per month. Email intake, shared assignment and
-  complete CSV history export are included. No chat channel. No setup fee.
-- Threadline: hosted, $24 per agent per month. Includes email, chat, shared
-  assignment and complete CSV history export. No setup fee.
-- OwnDesk: self-hosted, no software subscription fee. Includes email, chat,
-  shared assignment and complete CSV history export. The team must supply
-  hosting, backups, upgrades and incident response; their costs are unknown.
-
-These are hand-authored scenario specifications, not vendor research. Hosted
-prices exclude tax and assume six paid agents. There are no measured usability,
-reliability or migration results. A feature being listed does not establish
-how well it works.
-
----
-
-Recommend a first trial, explain what would make the other hosted option worth
-its extra cost, and identify what to verify before purchase. Treat self-hosting
-as an operational commitment rather than a zero-cost option.