Why: A rule that stops something on your laptop gives you no explanation, and an inbox for it would be one more thing to check.

Result: One record, the finding, is shared by your laptop and the company: it goes up whole, follow-ups come down onto it, and what was stopped in time stays the gentlest case.

Next: The Peterson conversation from peterson.md; then qnative's cycle from qnative-brief.md, whose step 0 is design's (each policy's configuration in the sidecar). Committed in 81f3ee59ee, unpushed; c149 builds the simulation's prevented rows against it. · waiting on Mark Peterson

Why: qcontrol's settings file had no page, and people will ask their agents to change it.

Result: A Config page with three sources and one check, and an agent that drafts the whole file for the person to apply. In the eval, 9 of 12 plain instructions got a correct first draft, and three one-line wording fixes brought the rest; the stand-in check still drifts from qcontrol's own.

Next: Phase 6: Guide 05 rewritten from a proposal into a contract, c145's configure step pointed at this page, the Outcome. Then F1 (link qconfig as the app's check) as a qnative cycle of its own, and the managed-machine instruction once C9 is answered. · waiting on Mark Peterson on C9; Tyler on Q6; engineering on the check, the write and the reload

Why: People learn security by seeing an incident, nobody can afford a real one, and an unlabelled pretend one is a hazard of its own.

Result: Six disaster stories that play in the lab's real dashboard, beat by beat on the person's Next, between one click on and one click off, with the findings worked out by the dashboard's own rules and pointed at one by one. Replaying them with one policy at Enforce shows what would have stopped each, and corrected the first draft in eight places. A show mode plays them unattended; the first story also plays in the native app.

Why: The desktop app will update often, and the part that installs updates had no screen, no choice and no notes.

Result: One Settings screen that says where an update stands, three ways to let it happen, a quiet trace after it does, and the same screen ready for a bigger rollout later. Eleven choices wait for Mark.

Next: Mark rules the eleven calls in review-1 (the preference's default, what invisible means, inline notes, skip, who owns the notes, one update or two, when an automatic install restarts, the version string, Settings' seat, the clock and the age line, the era as data). Then Phase 4: the rulings applied to the mocks, and the states pushed into qnative as stories through /gpui-story. · waiting on Mark's rulings; Tyler on signing, the updater, the feed's fields, qcontrol's update, package-manager detection and restart mechanics (T1–T6)

Why: The two tools our engineers use to watch the sensor are losing their home, and customers who measure every megabyte must not pay for them.

Result: A plan and nine rulings, then the first four phases built: the locks, the stream underneath, a page that picks fake or real data, and the live list itself, held to the web version by shared tests. The guide for hooking up a real sensor now asks for each thing once.

Next: Mark walks review stop 3's thirteen calls (qnative c3 review-3.md) and takes the 4-a-second readings of Live Activity; then Phase 4, Events, which needs his brief and mock first, and Phase 5, the Monitor, on the reconciled shapes. Still to be said: who gives the gate its expert review. · waiting on Mark's design for Events; Kamal's answers (the Guide's questions, page 4 for the Monitor feed); a Rust expert's review of the gate

Why: When a rule blocks something on your laptop you get no explanation, and the fix could flood you with alerts from every direction.

Result: Every message from head office now has one shape and three sentences, and you decide which kinds reach you and how; the first release carries only the connection receipt.

Why: Partners will run Qpoint on their own servers, and when we need to get in to fix something, there has to be a safer way than sharing a password or a screen.

Result: A partner opens a time-limited door for a stated reason, picks how much we may touch, sees everything we do, and the door closes on its own.

Next: Phase 0, prior art, can run now; Phase 1, the model as data, once the plane's identity model is ruled. · waiting on c134 D2 (the plane's identity model) and Tyler's say on where grants live

Why: Our shared parts box grew fast while we built, and nobody has checked it for doubles, missing labels or thin instructions.

Result: Every part gets a scorecard against five checks, doubles are merged or retired, and the parts the dashboard built for itself move into the box, so the next app starts with a full one.

Next: Phase 0 on Mark's word: the scorecard script and the annotation standard; then the census and its review stop.

Why: The company dashboard is stuck inside the program on each laptop, and its sign-in cannot be run by a customer on their own servers.

Result: The dashboard becomes its own web app, shipped as one package we can run or a company can run itself; both apps are mapped and the backend's 30 gaps are listed.

Next: Phase 1, the shell mock (sign-in, org, the qdash home with the global filter); Phase 2, the contract written for Kamal after the call. · waiting on Tyler's repo decision and Kamal's availability

Why: When a laptop blocks something risky, the person sees a block and no explanation.

Result: A finding becomes a short lesson, sent as a message to the small app and recorded as proof. The shape is drawn, the model is data, and the first lesson, about an unapproved MCP server on one real finding, can be taken end to end in the lab. The trainings are now files the design site publishes, and all three pilots (unapproved MCP servers, personal accounts, secrets in prompts) run end to end from real findings. The hand-off to the web app and the native app is written, and a library lets a person take any of them on their own; the brief is still in flight.

Next: The next topic trainings from the guide's list (D50, D53): Finding and Severity, Sanctioned, Exception and Scope, Endpoint and Harness, then the operator terms, each through the /training skill's topic section; c134 and c131 take handoff.md (the training page, the record, the library, topics and the operator's send); Tyler to validate D22–D27 with training.completed.self and D55; Peterson on personnel data and the self-report. · waiting on Tyler on D22–D27 and D55; c134's person frame, the plane repo, the copy at release and the operator's send; Peterson

Why: The way we sketch and review screens today depends on web pages, and the new desktop app is not a web page.

Result: The five-step loop stays. The bake-off put a web look-alike of three screens beside the real desktop app on the same sample data: the look-alike took an agent twelve minutes, the real screens an hour on a day of groundwork, and the two agree row for row. Mark picks which one is the medium.

Next: qnative c5 lands D21 in B (Status as the landing, Sensor, Activity) and the bake-off page wipes A over the new B; c131 D17's routes replace the bridge; a world per state retires the knob and the story parameter; Events, Config and Connect next through the same loop. · waiting on qnative c5 for B; c131 D17 for the routes

Why: The small program that watches a computer's AI traffic could not carry the web dashboard without getting heavy.

Result: A small desktop app will show what was found on this machine; a first test version runs on a Mac with very little memory, and the second phase shows it can look and read like our web pages.

Next: Phase 2 is complete (qnative c2 closed 2026-11-11). The V1 build starts from c130's shape.md and c0's name; the violation tour comes with qnative c4 (c137 Phase 3), the Status page with c132 Phase 4, D17's routes with engineering (c134). · waiting on c130 shape.md and c0's name

Why: The dashboard lived inside the sensor and made it heavier than the sensor's promise; the team decided to split them.

Result: A program with a researched primer, a measured spike, and seven cycles each with a plan, so the native app and the control plane can be built in parallel without losing the thread.

Next: Phase 2, the shape (shape.md), fed by the primer and the spike; then the pitch for Tyler's requirements session and c0's naming walk. · waiting on the date of Tyler's session

Data without the controls: one window, three reports, and every number honest about the time it covers.

Why: The Reports page was a placeholder. C-level people, auditors and IT need what the dashboard shows without access to the controls, and the pages disagree about what time they cover.

Result: In progress. One shared time window, a Reports catalog and a fully drawn Posture report are live in the lab. Deployment status and Inventory have their outlines. None of it is in qdash yet.

Next: Work through the open calls in c123's intents-pr5-review.md, then port to qdash. · waiting on Mark's review of the four reports

Cycle pages now tell a story, credit outside helpers first, and an explorer shows every cycle at once.

Why: A cycle's page showed its full record. You couldn't see at a glance why it happened, what changed or who helped, and the people outside Qpoint who shaped the work went uncredited.

Result: Every cycle now opens on a short story with pictures and credits, people outside Qpoint first. A new explorer shows them all, and open ones say what they're waiting on.

Next: Mark reviews the explorer and the stories, then rules on the review list: which cycles close and which outside credits stand. · waiting on Mark's review

Evidence, not compliance: the frameworks get one page and one verb, and a close reading of OWASP becomes a tour of what Qpoint can actually do.

Why: This week is about compliance frameworks, and our CISO advisor Mark Peterson is leading what they should mean in Qpoint.

Result: In progress. Framework detail is composed in the lab, with one Track verb on the listing and the detail, and five product tours are live, one of them built from a close reading of OWASP's agentic paper. Policies' frameworks strip, the listing's percentage and tracking that stages policies are still to do.

Next: Finish the frameworks cleanup page by page: Policies' frameworks strip (X1, X2), Compliance's percentage (X5), tracking that stages policies at Observe (F8), SOC 2's mappings. Take after captures. Check Peterson's revised intents against intents-redline.md §5 when they land. · waiting on Mark's read of the pages; Peterson's revised intents

Taming our own history: a box of unlabeled drawings, from the first Q sketch in 2023 to last week, made findable without moving a file.

Why: Years of sketches, boards and decks sat in a shared drive with no dates or links, so finding anything old was a struggle.

Result: All 1,137 files in the design drive can now be found, previewed and opened from one page, including 3,627 Illustrator artboards. Tying them to cycles is not done yet.

Next: Start Phase 3: tag each library file with its cycle, startup phase and design generation, reviewing with Mark one folder at a time.

A week of advisor conversations reshaped the governance model, and every lab screen was rebuilt to match.

Why: Our security advisor showed us how real security teams think about rules, and our screens still showed the old ideas.

Result: Now every rule has one simple switch, you see who a change affects before you make it, and all changes go live together. Seven screens changed.

Next: Close it once Mark confirms frameworks belong to c123, moving the carried-forward items there. · waiting on c123

Six drafts to one sentence: the method kept its shape and changed the problem it points at.

Why: Qpoint now works on AI governance, but our design method still used data governance as its main example.

Result: The method now names AI governance as its hard problem, and the /method page opens with a sentence Mark wrote himself after six drafts.

A small, finished favor: the logo page stopped describing the logo and started handing it over.

Why: The logo page described our logo but had nothing to download, so anyone without Figma had to ask for a file.

Result: Now anyone can pick a logo, a format, a size and a color, and download a ready-made file: 195 files from five masters.

Next: Nothing left to build; write the Outcome and close it.

The day the policy model collapsed into one page: an advisor's Oct 19 session, proven in the lab overnight, half of it overturned two days later.

Why: An Oct 19 session with our security advisor changed how policies work, and we had one day to see if the new idea held together.

Result: The new model ran end to end in the lab within a day: one policy page holds the switch and every exception. Ten of eleven questions were answered Wednesday morning.

Before telling the story of AI as Prometheus's fire, we made sure every quote is real; the talk is still to come.

Why: We want to give a talk comparing AI to the myth of Prometheus bringing fire, and every quote in it has to be true.

Result: Not a talk yet: a checked library of sources on the myth, on learning from mistakes, and on what people now say about AI, plus a sources page on the design site.

Next: Run the two pending research tasks (Christopher Alexander and the people overviews), commit them with the held Roesler edits, then close it. · waiting on GitHub access for the two cloud tasks

A proposal overtaken in hours: we designed shopping carts with approvals, the advisor and team said one shared cart is enough, and the cart idea is what shipped.

Why: Every policy edit took effect the moment it was made. Mark wanted to edit freely across pages, then deploy, discard or send for approval as one unit.

Result: The full proposal was overtaken within hours. Its core idea, making a change separate from publishing it, became the one shared draft we built two cycles later.

An outside illustrator got one page per blog post, and the first one shipped from sketch to published hero.

Why: Sarah draws the pictures for our blog, but she can't open our code or private notes.

Result: Each blog post now gets a page Sarah can open, with the idea and the deadline. The first one became the picture on a published post.

Next: Write the Outcome and close it; new briefs are content now, not cycle work.

Our advisor's fourteen notes turned out to be one machine; we drew it on eight screens, then spent two weeks of sessions taking parts out until the simplest version was left.

Why: Our advisor wrote fourteen ideas for governing AI, and our screens described the same things in older, mismatched words across separate pages.

Result: The fourteen ideas became one model and eight connected screens to try it on. Two weeks of advisor sessions then made the model smaller, and later cycles built that.

Next: Update the pickup note and the object model with what the October product sessions decided, then keep building in the lab as c118, c121 and c123 need it.

From cooking to order to cooking ahead: the demo stopped computing answers live and started serving them baked, and every page went from timing out to under a second.

Why: The live demo was too slow on small servers: busy pages timed out and showed "Can't reach qdash".

Result: Every answer the demo can show is now worked out ahead of time and served as files, so any page loads in under a second. The daily refresh is built but not running yet.

Next: Add the storage token to the demo Worker, deploy the scheduled baker, run one bake by hand to time it, then close it. · waiting on Mark's R2 token

We built a fake company that never sleeps so the demo always looks alive; the world worked, the servers did not, and that failure is why c113 exists.

Why: Showing qdash meant running it on a laptop, and its made-up company was frozen in July, so the "active now" parts looked dead.

Result: We built a public demo whose fake company keeps working around the clock, in four sizes. It worked, but the servers were too slow, so the next cycle replaced how it is served.

The cycle numbers stopped telling time, so the work got a calendar: every week now has its own page.

Why: Cycles now overlap so much that their numbers no longer tell you what happened when.

Result: The cycles page gained a week-by-week view, and every week has its own page with what started, what closed, the code changes and the screenshots. The backfill and digest are still to come.

Next: Hand the records backfill and the digest rewire to c124 or the backlog, then write the Outcome and close it.

The Activity page stopped counting sessions and started answering who used how much, and what it cost.

Why: The Activity page counted sessions, but people ask about tokens and cost, and two of its cards weren't earning their place.

Result: Activity is now two rows of three: sessions, tokens and cost, then providers, models and harnesses. The cycle's write-up isn't finished.

Next: Nothing left to build; write the Outcome and close it.

After ten cycles of placeholder landing pages, the home page became a newspaper front page for the whole fleet.

Why: The Inventory and Organization landing pages had said "Design in progress" for about ten cycles, and the home page had nothing on it.

Result: Those two menu items now just open their lists, and the home page shows the whole fleet at a glance: 35 small summaries, each matching its own page.

The dashboard stopped saying "all clear" when it simply hadn't heard back.

Why: While loading or offline, the dashboard showed comforting all-clears like "Fleet is clean" or a perfect score of 100, before it knew anything.

Result: Every page now tells loading, failed and truly empty apart. A failed save says so and undoes itself. The false all-clears are gone.

Three dashboards became one: the app everyone already used became the app the product ships, and nothing was lost on the way.

Why: The product still shipped an old dashboard nobody worked on, while the app everyone worked on shipped nowhere.

Result: The app everyone used became the one the product ships. The old apps were archived, not deleted, and their best fixes came across first. Tyler's review is still to come.

Next: Nothing left to build; move the Outcome to the history and close it, leaving the pull request review parked.

A long page used to lose its own name when you scrolled; now the name rides along at the top, and nothing on the page jumps.

Why: When you scrolled a long page, its name scrolled away with it, so you could lose track of where you were.

Result: The page name now stays pinned at the top beside the filter, shrinking out of the way as you scroll. It shipped on every qdash page.

A cost page that listed everything and answered nothing gets redrawn around the three questions real buyers ask.

Why: The cost page was built before the app knew much about cost, and it answered none of the questions managers, finance and the CFO actually ask.

Result: Not finished yet: a redrawn Cost Center mock answers spend, pace and rate first, with one table that breaks spend down eight ways.

Next: Commit the cycle and its mock, get Mark's review of mock round 2, then port the cost page to the app. · waiting on Mark's review

A one-line bug fix exposed three sticky bars that didn't know about each other, and the answer was to make them one.

Why: Long tables never kept their header in view, and fixing that made the header slide under the section tabs.

Result: One sticky bar now holds the section tabs and the filter together, and table headers stick right under it on eleven pages.

One review day reorganized the whole menu and taught three pages to show which way their numbers are heading.

Why: Mark's next review reorganized the app's menu and asked, page after page, how to show the trend next to today's number.

Result: The menu now groups pages by job, Sessions became Activity, Teams shows a spend trend per team, and Users leads with who needs attention.

A page of review notes became thirteen careful page changes, each photographed before and after.

Why: Mark reviewed fourteen app pages and left a page of notes; each note needed to become a real change.

Result: Thirteen pages changed one at a time, each previewed and reviewed. Tiles say what they count, and Teams leads with coverage.

A renderer that never found a product home meets a question every detail page asks, and the cycle hands it to a designer instead of drawing it.

Why: Every detail page lists what a thing can reach, but lists hide the shape of the answer, and our 3D map tool had never found a real job.

Result: Not finished yet: nothing is in the product. A designer has the brief, six example sessions now tell the story of a broken rule in plain words, and qmap has started staging the first one.

Next: Keep staging the six stories in qmap c29, which so far has flows for the first one only. Then settle how tools are drawn, and which characters to draw next. Deploy when the sessions page should be readable off this laptop. · waiting on the designer's first round is still not on record, though the qmap work isn't waiting on it

Ten false starts at "the landing" became one deliberate bake-off, and its best drawings became full pages, then the small cards on Home.

Why: The app's big overview pages had split into four empty placeholders, and ten earlier attempts at "the landing" never reached a pick.

Result: Eight bake-offs and composed mocks for Home, Inventory and Team, plus new library pieces. Later, Inventory and Team folded into Home's small cards.

Next: Get Mark's picks on the Home and Fleet mocks; until he has time, park it with a pickup note. · waiting on Mark's picks

Every page checked, a rulebook written, and the whole app rebuilt on it twice, so the method could be judged, not just the result.

Why: Every page of the dashboard fetched its data its own way, and nobody had written down how pages, parts and data should fit together.

Result: A written rulebook for how pages get data, and every page rebuilt on it, twice, by two AI builds. One build became the product's app a few days later.

Next: Nothing left to build; write one closing Outcome that records the Fable app as the choice, and close it.

The sidebar learned to say where you are, and its look was dialed live on the demo.

Why: Inventory had grown nine listing pages, but the sidebar listed nothing under it, so you couldn't tell where you were or reach them easily.

Result: On any Inventory page, the sidebar now opens to show its nine listings with the current one lit. The Fleet section moved up to second.

A real inconsistency, a careful plan, and no work yet.

Why: The same AI tool, like Claude Code or Cursor, is drawn differently on almost every page: different logos, sizes and labels.

Result: Not built. A plan exists to survey every place a tool is drawn, settle ten questions with Mark, then make one shared chip. Nothing has started.

Next: Give it a new cycle number and decide whether one shared harness chip is still wanted; if not, close it.

The page histories gained their true first chapter: Devin's June prototype, dug out and brought back to life.

Why: The page histories began at our first design mock-ups, but the product really began earlier, as a quick prototype Devin built in June, with almost no pictures left.

Result: Fifteen page histories now open with that prototype: six screenshots recovered from old code history, and fifteen new ones from rebuilding it and feeding it replayed activity.

Screenshots learned which page they show, and a page's history became something you can scrub through.

Why: Screenshots of the same page piled up across cycles under different names, with nothing tying them together, so nobody could see how a page had changed.

Result: Every capture now names the page it shows. A new view lines up each page's history and compares any two moments by wipe, fade or side by side.

Two finished tools fought over one spot; joined, they became the one strip above every table.

Why: Every listing had two controls fighting for the same spot above its table: the quick filter and the new column picker.

Result: One strip now holds both: filter keys on the left, Columns on the right, across every listing. Three known gaps and the promised visual design are still open.

Next: Write the Outcome, move the three known gaps to the backlog, decide whether the Figma design is still owed, and close it.

Mark's meeting notes became a routine: one page, one plan, one preview, one review.

Why: Mark's page-by-page meeting notes became work by hand, and the hand-offs leaked: lost lines, misread fragments, and every helper briefed one by one.

Result: A todos skill now reads the notes straight from Logseq and writes one plan per page. Its first run made 17 plans, all carried out that day, one page at a time.

Next: Nothing left to build; write the Outcome, list the follow-ons, and close it.

A small Columns button gave wide tables room to breathe, and the next cycle carried it into every listing.

Why: Listing tables were getting wide, and nothing let a person hide the columns they didn't need.

Result: A Columns button now opens a checklist that shows or hides table columns, with a badge counting what's visible. The next cycle moved it into the library and onto the app's listings.

Next: Nothing left to build; write the Outcome pointing at c95 for the extraction, and close it.

Nine days took the mocks off the film set and into the product, one shared part at a time.

Why: The new page designs lived only as mocks on made-up data, while the real app still had hand-made filters and older pages.

Result: Over nine days the mocks became real pages on real data: one filter with an always-on time window, a chart on every listing card, one frame for every detail page. Phase three stayed open.

Next: Write the Outcome of what each thread landed, hand the open items to the current app's backlog or drop them, and close it.

Two stat cards from a mockup became one flexible part, and the idea behind it got a name.

Why: A new stat-card design needed one flexible part, and Mark saw the pattern our map tool had found: a rich base with a few ready-made presets.

Result: DataMachine shipped in the shared library with two copyable presets. The base-plus-presets idea is now written into our design method.

Separate mock rooms became one walk-through behind a front door, the last stop before the real app.

Why: Each page mock lived alone on the design site, and Team Details and a Devices list didn't exist, so nobody could click through the whole flow.

Result: Seven pages now sit behind an app-like sidebar and click through as one flow. Three were reworked against new annotated mockups. The record's Outcome was never written.

Next: Nothing left to build; write the Outcome pointing at c92 for the real-app port, and close it.

A ring where there's a whole, a plain number where there isn't: two listing mocks taught one honesty rule.

Why: The Teams page showed coverage as bare fractions, and there was no page listing sessions at all, only one session at a time.

Result: Teams now shows coverage as rings and names the people who need attention. A new Sessions page puts the sessions worth a look first. Both were early mocks, later copied forward.

Next: Nothing left to build; move its finished Outcome to the history and close it.

The filter left the one app it was stuck in and came back as a single bar the next cycles used everywhere.

Why: Our older web app had a working filter bar that no other project could reuse, and its redesign existed only as mockups.

Result: The old filter now lives in the shared library as a legacy set. A rebuilt bar and a new quick-filter strip follow the mockups, and both share one filter state.

Next: Nothing left to build; drop the step for the unused app, move the leftovers to the backlog, and close it.

A hand-drawn week of coloured squares became a chart that counts from seven days to sixty without growing too tall.

Why: We needed a chart of activity over days, like sessions per AI tool each day, that works for a week, a month or two months.

Result: A new shared chart draws each day as small stacked squares, one lane per series. It scales from a week to two months and is documented with many examples.

A name and a blank page: there is no story to tell.

Why: Unknown. The cycle was opened with a name and an empty prompt file, and nothing says what it was for.

Result: Nothing was done. No plan, no pages, no images. Any guess at its purpose would be made up.

Next: Ask Mark what Machine Status was meant to be; if nothing, close it as abandoned or delete the empty folder. · waiting on Mark's answer

Mark's labelled sketch of a chat became five shared parts, down to the little tail on each speech bubble.

Why: We needed to show what a person and an AI agent said to each other, and the earlier attempt was only sketch code on a demo page.

Result: Five shared components now show a chat session: speech bubbles, folding tool calls, and a small ruler for jumping between turns. They're documented and reusable.

Four ways to ask "what is design doing right now?", and a grid that answered it on paper but never reached the real page.

Why: The cycles page was a good archive, but it couldn't say at a glance what design was working on, what was stuck, and what needed a decision.

Result: Four directions, rough then real, and one promoted design: a grid of every cycle by stage and need. The real cycles page never adopted it.

Next: Write an Outcome saying the production slice was never built because later cycles took the page another way, then close it.

A worry written down in one paragraph, whose practical half was solved the same night by someone else.

Why: Our shared component library had just become public, which made cloud installs easier, and Mark had misgivings he wanted to explore.

Result: Not started. The cycle is one paragraph. The practical question, installing the library in the cloud, was answered the same night by c82's run.

Next: Ask Mark whether the worries about a public library need their own cycle; if not, close it as answered by c82. · waiting on Mark's answer

Parked in the morning, run the same night: the cloud built seventeen pages unattended and taught us to save after every step.

Why: Mark wanted to know whether a whole design cycle could run in the cloud while his laptop was closed.

Result: It could. One overnight run built all seventeen Phase 1 pages unattended. But the cycle has no formal record yet, and the index still calls it parked.

Next: Write a short record from the first-run notes, answer or retire its two open questions, and close it.

Seventeen pages drawn at once on one made-up company, then four of them drawn again after the advisor walked them.

Why: Phase 1 called for 17 dashboard pages about people, teams and their AI tools, and the product had only an early prototype.

Result: All 17 pages exist as mocks on one made-up company, each opening with a one-line verdict and a calm all-clear version. Four got a second pass after an advisor walkthrough.

Next: Nothing left to build; write the Outcome, capture the four second-round pages, and close it.

A two-word sticky note: there is no story to tell yet.

Why: Unknown beyond the title. The only note says a help overlay was "currently in design" somewhere else.

Result: Nothing was built or written here: no plan, no pages, no images.

Next: Ask Mark what the help overlay was; if nothing picked it up, close it as abandoned. · waiting on Mark's answer

A confusing error in chat apps traced to one missing final step, handed to engineering, and fixed.

Why: Chat apps running under our sensor kept failing with a decompression error, and nothing showed that our own proxy was the cause.

Result: We traced it to our proxy never finishing one kind of compressed stream, and wrote down the fix and a missing test. Kamal fixed it three weeks later.

Next: Nothing left to do; write the Outcome noting qcontrol's upstream fix, and close it.

An advisor's list of verbs and deadlines became the rules for a finding, and three days later the product's findings page ran on them.

Why: An advisor told us what security teams do with a finding and how fast they must fix it. Our reports assumed that workflow, but nothing in the product did it.

Result: Findings in the product now group under their rule, carry a status and a remediation clock, and can be ignored or accepted as risk with a reason. It shipped within three days.

Next: Nothing left to build; write the Outcome, hand its open threads to the governance cycles, and close it.

Four reports a CISO actually hands out, drawn in full, and a front page that is only their summary; the final card pick never came.

Why: Our advisor listed four reports a security team needs, and our founder framed the landing page as a summary of them. None of the four existed yet.

Result: All four reports were mocked in full on one shared shape, with a landing page of four summary cards. Mark never picked a card style, and on 2026-11-03 the work closed into c128 Reports, which carries on its report shape and the Board report's summary.

A session became something you can read, first as a layered record and then as a chat, and the chat idea outlived the cycle.

Why: The product records everything an AI session does, but there was nowhere to read it: a link promised a session's full story and went nowhere.

Result: Two mocks: one session read at four levels, from receipt to raw events, and a bake-off reading it as a chat. Not finished yet: the timeline, footprint map and final page were never built.

Next: Write the Outcome saying the chat idea went on to Session Details, mark the unbuilt mocks as dropped, and close it.

A one-line wish that was never started; a later brief to Sarah takes up the job.

Why: The colors behind light and dark mode were harder to define than they needed to be, and the wish was to make them simpler.

Result: Not started: only a one-line note was ever written. The same job now sits in a dark-mode brief that asks Sarah to choose the dark colors by eye.

Next: Never started; close it as superseded by the dark-mode brief.

A hand-shaped card became a reusable piece on the design site, but never made it into the shared library.

Why: The cycle cards on the atlas listing were hand-written markup. Once Mark finished shaping them by hand, they were meant to become a reusable part.

Result: Half done. Mark's card became a local component the same morning and now serves three pages. It never moved into the shared library, and the archive's similar card was never switched.

Next: Decide whether the cycle card moves into the shared layer; if not, write a short record of the local extraction and close it.

A good question about how we build parts, asked and not yet answered.

Why: We had principles for shared components, but no rules for the moment of making one: a reusable pattern or a one-off special part, shared or local?

Result: Not started. The question and where to look for answers were written down; no rules, skill or worked examples were produced.

Next: Add a pickup note and list it in the cycle index so it reads as parked, with the qdash app as its model when it resumes.

Adding an integration became a guided setup that shows you the message before anything is sent.

Why: Adding an integration led to a disabled form that said "not wired". Operators had no way to set one up, and no help finding the keys and IDs.

Result: A guided setup window for all 11 integrations, each with real fields and step-by-step instructions, reused for editing. Notification channels also preview the exact message they'll send.

Next: Check that the current app kept the setup modal, write the Outcome, and close it.

Cycle notes from eight repositories became one browsable album, with the missing photos taken.

Why: Cycle records were scattered across eight repositories, and many earlier cycles had live pages but no pictures. Nobody could browse the whole history in one place.

Result: Every cycle in every repository, 151 at the time, got its own page with its write-up and pictures. About 420 screenshots were taken, many showing an experiment in eight or more states.

A 2007 thesis, the root of our method, became a book you can read on a Kindle.

Why: Mark's 2007 master's thesis is the root of Qpoint's design method, but it survived only as one PDF of wide two-page spreads, hard to read on a Kindle.

Result: The thesis now lives in the repo in three forms: the original PDF, a Kindle e-book with its pictures, and a single-page PDF that reads as designed, plus its full text.

A day of sweeping the workshop: cycles filed, tools rebuilt, and the method put where every session reads it.

Why: Our tools and habits had grown faster than we tidied them: dozens of stale "active" cycles, uncommitted work, outdated commands, and a design method agents never read.

Result: Order restored in a day: 22 cycles filed, the backlog committed, commands rebuilt as skills, the method loaded into every session, and a script that photographs every page.

Next: Rule the six flagged cycles from the completion audit, write the Outcome, and close it. · waiting on Mark's rulings on six flagged cycles

The landing page's first job was settled, drawn fifteen ways, then hand-drawn as three cards.

Why: The dashboard's first page overlapped with the inventory page, and nobody had settled what a person should see first when they log in.

Result: An order for the first page: a one-line verdict, what needs you, then doors to each area. Seven mocks, ending in Mark's three cards. Picks never came; later cycles shipped it.

Next: Write the Outcome saying the landing page shipped through later cycles, ending with c109, then close it.

The Teams page learned how to sort people into teams, then spent a day finding how much picture a summary can carry.

Why: The Teams page repeated the cost table, made team membership a free-text box, and had no way to match observed people to the real organization.

Result: Eight page versions and nine studies of the team summary strip, ending at a ship candidate. The review never happened; its best ideas fed later landing and Teams work.

Next: Write the Outcome saying c100, c92 and c103 took the work over, then close it.

A switch between dollars and tokens taught us the table needed both columns.

Why: The cost page showed only dollars. Dollar figures are partly estimates while token counts are measured, so we wanted a switch between the two.

Result: Built in the product, then pulled back the same day to be worked out as a mock first. It never shipped; a later redesign showed both units side by side instead.

The hand-built rule kit became a short list of ready-made policies, chosen by the frameworks you must meet.

Why: Every control had to be hand-built from rules, conditions and actions. That was more setup than an operator should ever have to face.

Result: A catalog of 17 ready-made policies, each switched on with a toggle and driven by the compliance frameworks you choose. It replaced the controls page in the product.

Next: Nothing left to build; move its finished Outcome to the history and close it.

Three overlapping pages were mapped, and one small editing card made it into the product.

Why: Several people had built overlapping dashboard pages for controls, policy and compliance at the same time. The numbers disagreed and the same table appeared twice.

Result: A clear map of the overlap, a ranked list of quick fixes, and an edit-in-place card for controls that shipped to the product. The deeper redesign went to the next cycle.

Next: Nothing left to build; write the Outcome and close it.

A quick walk through the dashboard, room by room, before the redesign started.

Why: We wanted a quick, honest picture of where each page of the product dashboard stood: working, restyled, designed, or polished by hand.

Result: A 22-row table, made in one sitting. Every page worked and wore the new look; five had a design pass; none had been fine-tuned by hand.

Making partners insiders: research, a portal, two tracks and a real weekly digest, waiting on four decisions.

Why: Build partners were about to plug Qpoint into their own systems. They would need to see what we're doing, where it's rough, and feel part of the team.

Result: Research, a partner portal mock, a two-track program and a weekly digest built from real work all exist. The program decisions are still waiting on Mark, so it's parked.

Next: Leave it parked and fix its status note; at pickup, start from the program decisions waiting on Mark. · waiting on Mark's program decisions

Eleven rounds of ideas, and the catalog that won went into the product.

Why: The Integrations page was a list of what might connect someday, and the Teams page had no teams. Neither page matched its name.

Result: After eleven rounds of ideas, Integrations shipped in the product as a catalog grouped by what you want to do, with connected tools showing live numbers. Teams moved to its own cycle.

A good diagnosis that waited for full attention, until another cycle took the urgent half.

Why: A look at how we use AI helpers across all our projects found the daily work strong but the shared plumbing weak: copied files, no automation.

Result: Nothing was built here. The cleanup half was done by c69; the rest, like shared plugins and automatic checks, waits as notes for a future cycle.

A name and an empty page; the work it named happened next door.

Why: A placeholder for going deeper on the inventory page. Its purpose was never written down.

Result: Nothing was built here. The deeper inventory work happened in c59's last rounds instead.

Eight rounds turned a flat agent list into a page that opens on who's alive, and its agent card shipped.

Why: The inventory page listed agents in one flat table. It didn't say which were alive right now, or what was running unwatched.

Result: After eight rounds, inventory leads with how many agents are alive, how much is watched, and what's at risk. Its agent card shipped into the product on real data.

Next: Nothing left to build; write the Outcome from the last iteration and close it.

The pawn got its first badge, sized to the design by checking side by side.

Why: The new pawn needed its first real home: a small card that says what an agent is doing and where, at a glance.

Result: A compact agent card and its "Waiting for your input" bubble now live in the shared library, matched to the design after two side-by-side reviews.

One pixel robot learned to show five moods.

Why: We had pixel-art figures for AI agents but only one picture, so they couldn't show whether an agent was working, asleep or stuck.

Result: The agent pawn now shows five states by stacking art: binary digits while working, zzz when idle, a red burst on error, a bubble when it needs you.

Three compliance pages taken from Figma and made clickable.

Why: Figma had new designs for turning compliance frameworks on and off and seeing their requirements, but nothing to click through.

Result: A frameworks list, an OWASP LLM Top 10 detail page and a findings page now work as mocks, with toggles that update the progress.

Reading the product to find out who it was for, before anyone could be asked.

Why: The dashboard had grown by following the technology. We didn't yet know who it was for, and there were no customer calls to ask.

Result: Reading every page against eleven kinds of buyer showed it fit a hands-on security engineer best. Those guesses now live in market-analyst, and calls have since confirmed most.

Next: Write the Outcome, copy its four open questions to market-analyst, and close it.

A Figma table became a real page, and its pieces became shared parts.

Why: A new Figma design turned the policy page from a few summary cards into one table where every rule could inherit or override its settings.

Result: The table page was built from the design, five of its parts and a tab strip joined the shared library, and a real table bug was fixed on the way.

A paint-sample drawer for dark mode, so no color attempt gets lost.

Why: We wanted a softer dark mode, but trying colors meant editing code and losing the last attempt each time.

Result: A color drawer on every design-site page now edits light, dark and a new "subtle" dark side by side, and saves each attempt as a file.

A walk through every room of a scattered product, before anyone started tidying.

Why: Qpoint's product had grown into several separate apps, each built by whoever needed it. Nobody could demo one clear product.

Result: We mapped every app and every screen, and found the new dashboard could only look, not act. The rebuild then happened in later cycles; this one was never closed.

Next: Write the Outcome naming the cycles that carried each goal, send the two leftover goals to a seed and to www's cookie-consent cycle, then close it.

Five new parts, and an AI agent's profile page built entirely from them.

Why: A new page about a single AI agent had been designed, and it needed visual parts we didn't have yet: score gauges, a donut chart, metric cards.

Result: Five new parts, each with a demo, and a full mock of the agent page built from them. It also started the first pixel-pawn figure.

Every fix moved the problem to another builder, so we stopped using one.

Why: Pushing our work no longer updated the live design site. Builds kept failing on access problems, and the site froze with broken pages.

Result: We stopped building in the cloud. One command builds the site on Mark's laptop and Cloudflare simply serves it. It has worked since September 27.

The site that documents our parts stopped hand-making its own and started using them.

Why: The design site documents our shared parts, yet it still hand-built its own callouts, code blocks, back links and tables instead of using them.

Result: Eleven new shared parts went into the layer, and every hand-built copy on the site was swapped for them. The site now runs on its own system.

A brief that gave our AI maps a cast of eleven characters.

Why: Our maps of AI sessions used throwaway placeholder figures, with no shared look for agents, tools, files, secrets or policies.

Result: A brief describing eleven characters, the states each passes through, and how policy events look. Later work built the pawns from it.

One document so a newer designer could make the dark site alone.

Why: The brochure site was being drawn in light mode, and a junior designer needed to make the dark version on their own.

Result: A brief they can work from alone: every color value, contrast minimums, and guidance on surfaces and illustrations, with room for their own choices.

One nine-second incident became the story every policy page tells.

Why: Our policy wireframes still used old-style data like where data is stored, when the real risk is now AI agents reading secrets and running destructive commands.

Result: The policy wireframes now tell an AI agent story: six agent policies, and one real incident traced second by second. Good enough for demos.

A careful plan to design in Figma first, overtaken by building straight in code.

Why: The product was turning toward AI, and Figma had drifted away from the code. The plan was to rebuild a clean Figma library first, then redesign the dashboard there.

Result: A thorough plan and several prep lists, but the Figma work never happened. The redesign went straight into code instead, in later cycles.

Next: Write an Outcome saying the plan was never followed because the redesign went code-first, then close it.

We wrote down how to map a company's AI, and a week later qmap drew it.

Why: qmap could show one AI session, but not a whole company's AI: which agents were active, what code they touched, and which tools they used.

Result: A plan and a sample data set for that company-wide map. qmap built it a week later, exactly to the plan, so the design side was done.

A careful plan to bring qmap's session map home, waiting on a signal that never came.

Why: qmap's 3D map of a live AI session lived only as an experiment. We wanted it as a real page on the design site, without copying unstable code.

Result: A plan only. It says how to bring the map over cleanly, and waits for qmap to settle first. qmap moved on, so the plan was never carried out.

Next: Write an Outcome saying the qmap gate never cleared and the plan stays as reference for c101, then close it.

A brief became a working prototype that turns noisy traces into a readable story, then the idea moved on.

Why: A brief from c38 described a screen that shows how many small, noisy events become a short readable story. It needed to become something real to try.

Result: A working prototype shows the idea with sample sessions and can read a local qcontrol feed. Its open questions were never answered, and the idea moved into later work.

Next: Write a short Outcome saying the idea moved into the session pages and the prototype stays as reference, then close it.

Our block-art editor became a part you can drop into any page, and the design site shows it working.

Why: qpixel, our block-art editor, was a full web app, unlike our other drawing tools, so other projects couldn't drop it into a page.

Result: qpixel is now a small library any Vue project can import, and the design site shows the full editor working live.

All our design history on one line you can scroll, with each piece opening right where you are.

Why: Our design history was spread across the archive, the history pages, cycle records and git, with no single place to see what happened when.

Result: A first timeline: archive items and milestones on one scrollable line, with filters and zoom, and the item's page opening right below it. Detail pages and git history were left for later.

Before building anything, we wrote down six screens that would make qcontrol's evidence easy to trust.

Why: qcontrol's engineering was moving fast, but how to show and explain what it sees was still mostly in people's heads.

Result: Six short design briefs, plus shared rules for showing confidence, sources and live state. One of them became a working prototype in the next cycles.

We followed the missing baton through every handoff and found it was never passed.

Why: The new map of an agent run showed network activity live, but runs that only touched files never appeared. We needed to know where those events were lost.

Result: Found it: qcontrol wasn't sending file events out at all, so our map code was fine. The map is now described honestly as a network map, with test data for the rest.

Four rounds of reading qcontrol's code found the stream we could draw, and a new qmap cycle drew it.

Why: qcontrol watches what programs and AI agents do on a machine. We wanted to know whether that stream could feed our map and traffic pictures.

Result: Four rounds of research found the way in, qcontrol's event stream, and planned a map of one agent run. It was built as a new qmap cycle. One early mistake was caught and corrected.

Next: Nothing left to build; write a short record pointing at where its plan went (qmap c22 and c37) and close it.

A bare terminal got a welcome screen, and the tools built for it became a project of their own.

Why: People trying the qcontrol demo saw a bare terminal. Nothing told them their AI agent was now being watched, or that this was a Cisco and Qpoint product.

Result: A finished welcome screen for the demo terminal, drawn in block characters with a Cisco plus Qpoint logo, and notes for Jon to build it. The toolkit behind it became qpixel.

Two crowded diagrams of qcontrol, redrawn plainly; nothing says why.

Why: Not recorded: the prompt file is empty. The files suggest a need to explain simply how qcontrol, the tool that sandboxes AI agents, is put together.

Result: Two crowded architecture diagrams of qcontrol were redrawn as two plain ones: three commands talking to an engine, and the four steps a watched call takes. Nothing says where they were used.

Next: Ask Mark what the diagrams were for, write a short record of them, and close it. · waiting on Mark's answer

Pictures instead of tables: three security questions, each answered by a drawing.

Why: Qpoint records what AI agents do (sessions, models, keys, tools, files) but showed it only as tables. Could pictures make it clear to a security team at a glance?

Result: Four working sketches each answer one security question with a picture: what did this agent touch, who connects to which model, which tools are exposed. Later cycles carried them on.

A Figma policy page rebuilt from seventeen parts already on the shelf.

Why: The security overview had a mock, but policies, the rules a security team sets and watches, had no reference pages yet.

Result: The policy page was rebuilt from a Figma design using seventeen existing parts and nothing new. The listing stayed empty until a later cycle. A repeatable Figma-to-page method came out of it.

The design site learned to show whole pages, starting with the security overview.

Why: The design site showed components one at a time but never a whole page. The engineer building app pages had no clean example of how the parts fit.

Result: The design site gained a Pages section. Its first entry rebuilt the security overview from shared parts, and five health and severity parts moved into the shared library.

A friendly tour for newcomers, written once for design and never rolled out further.

Why: Each project's instructions were written for AI helpers: what and how, never why. Someone new had no friendly way to learn what a project is for.

Result: A /tour command now walks a newcomer through the design project: its purpose, its neighbours, key ideas and common tasks. The rollout to other projects never happened.

Six drifting copies of the same instructions became one master with room for local habits.

Why: Six projects each kept their own copy of the instructions for running cycles, and the copies had drifted apart. Updating them meant six edits and guesswork.

Result: All six projects now share one set of cycle instructions, kept in design, with room at the bottom for each project's own rules. qflow and qmap moved to the same layout.

Two drawers of overlapping parts, sorted, and the newer one relabelled so its name says what it holds.

Why: The shared library had two overlapping families of data components, and nobody could say which to use. One family was called DataMachine, a name that said nothing.

Result: All 22 data components were sorted into replaced, keep or look again. DataMachine became DataMetric in all three projects, and a new page explains which to use.

The tools that build every demo got demos of their own.

Why: The design site documented only five of its eleven demo-building tools. The control-panel pieces had no page, so people building demos could not find them.

Result: All eleven tools now have a working demo on the design site, on two pages kept off the public component list.

Four laptop-only projects got ready for the web, with a brief for the person who would host them.

Why: Four of our internal projects ran only on a laptop. Teammates in sales or engineering had no way to simply open them in a browser.

Result: All five repos were made ready to build as plain web pages and merged, the shared library was published, and Jon got a hosting brief. Going live finished in a later cycle.

A habit of tasting while cooking became principle eight, with a page that shows what still needs tasting.

Why: We already built each shared part by using it on the design site first, but only by habit. Nobody could see which parts had really been tested.

Result: It is now principle eight: building a part and documenting it are the same act. All 87 parts were audited, a coverage page shows the gaps, and the worst were filled.

Two experimental libraries got real names and live pages on the design site.

Why: Our two visualisation libraries, a 3D network map and a 2D traffic flow, were nearly ready but undocumented and hard to use outside their own projects.

Result: Both got proper package names and live demos on the design site: an overview of when to use which, and a page for each.

A rule about where things go: everything you can see goes in the shared pantry.

Why: The shared library already held product-specific parts, and the urge to 'keep it pure' cost more than it saved. The product also ran an old copy of the demo tools.

Result: Settled: every visual part lives in the shared library, and only parts wired to live data stay in a project. The product dropped its six old demo-tool copies.

One cycle after giving the card an open shelf, we saw only one thing ever went on it and built that thing in.

Why: The space beside the policy card only ever held a violations table, so leaving it as an open slot made every page rebuild the same table.

Result: The violations table is now a shared part of its own, and the card takes a list of samples and draws the table itself. A policy page can use the table alone.

The policy card's frame came off so allow-list cards could wear it too, in a new light blue.

Why: The policy page needs cards for allowed apps, datastores and vendors that look like policy cards but hold different content. That look was locked inside the policy card.

Result: The border, shadow and ribbon became their own wrapper with five colour states, including a new light-blue one for allow-lists. The policy card uses it and looks the same.

An alert rule written as a sentence went from drawing to shared part, and its sentence pieces turned out to be useful everywhere.

Why: People need rules that say when a policy violation should raise an alert, how, and how often, set up in a way that reads like a sentence.

Result: An alert rule card was built to the design, then its sentence pieces were moved into a shared set of their own so filters and other rules can use them.

The policy card learned to carry its violations beside it, just as the security design drew it.

Why: The security design shows each policy card with its violations table beside it. The card had no room for that, and the little data-flow picture had no shared part.

Result: The card gained a space beside it for the violations table, and a new part draws the data-flow picture: a dot, a tag like PII, and an arrow.

The design site started to look like the brand it teaches, a step at a time, before later rebuilds took over.

Why: The design site explained the brand but did not look like it. Mark wanted to bring the Qpoint look to it in steps, designed first in Figma and Illustrator.

Result: Component pages gained three view modes that remember your choice, examples became easier to read, and a resize bug was fixed. Later rebuilds replaced most of the look.

A saved paper with nothing written around it, which turned out to matter seven months later.

Why: Mark saved a 2005 design-method paper by Axel Roesler, his old thesis chair, about the hard leap from understanding people's work to first design ideas.

Result: Nothing was built and no notes were written. Seven months later the same paper became the top-ranked source behind our design method.

Next: Ask Mark whether it was meant to be more than a saved paper; if not, close it as carried on by the sources work. · waiting on Mark's answer

Reading 36 product files turned the library's hardest part into a guide anyone can follow.

Why: The shared table is the most complex part in the library and is used across the product, but its docs were a thin demo unlike real use.

Result: Eight table demos now use realistic data and line up properly, and a new guide walks from the simplest table to how the product really builds one.

Mark wrote down why the shared library beats the old playground, so colleagues could see the logic.

Why: Colleagues needed to understand why screen parts now live in one shared library, and why the old practice playground kept breaking.

Result: A new Layer page explains the shared library, what it gives every project and how it beats the old way. The icon docs were tidied and a table bug was fixed.

A design tool handed us a messy first draft of the policy card, and a cleaned-up version became a shared part.

Why: We had Figma designs and a tool that can read them, but no tested way to turn a Figma component into a working part of our shared library.

Result: It worked: the policy card came out of Figma as a real shared part, with four sizes and two states. The output needed tidying, and the Figma-to-code link was left for later.

A page of marketing blocks laid out for Figma, and then the Figma work never came.

Why: The marketing site's twelve building blocks existed only in code, so nobody could lay out or review a page in Figma.

Result: A plain page showing all twelve blocks was built, ready to send to Figma. The Figma library and its links to the code were never made, and the cycle was paused.

Each project got a phone list of its neighbors, so work can cross between them.

Why: Qpoint had eight or more projects, each expert in something, but none knew what the others offered. Using two together meant knowing where everything lived.

Result: Each of the four main projects now lists its neighbors: what each is for, when to use it, and where its data lives. AI sessions can now borrow across projects unaided.

A landing page for security buyers, drafted in words and paused before it was built.

Why: Sales calls showed security buyers bring urgency, while engineering buyers bring interest but rarely buy. The new policy dashboard designs gave us a story for security teams.

Result: A first draft of the page's words exists, in seven sections, with two dashboard designs as proof. The page was never built, and the cycle was paused.

One long page of patterns became a grouped index of short pages.

Why: The Patterns page had grown to 18 patterns on one long scroll, and its index listed only 12 of them.

Result: Patterns now live on short pages by group, with an index laid out like the components index, and one page that still shows all 18.

A rename fixed a naming clash, and seven more website blocks joined the shared kit.

Why: The kit's "content" group clashed with a plugin that strips that word from names, and seven more website blocks still lived only in the website.

Result: The group was renamed "prose", which fixed the clash. Seven more blocks moved into the kit, so the website keeps no copies of these twelve, and all have demos.

A video to show the team how design works here: planned in February, never recorded.

Why: The team had never had a proper look at the design side's thinking and tools. Engineers and sales each needed different pieces to use them on their own.

Result: Not made yet. There is a plan for a short recorded video in three parts, a list of who it's for, and an open question about how it should start.

Next: Ask Mark whether the video is still wanted; if yes, park it with a pickup note, and if no, close it. · waiting on Mark's answer

A 2007 thesis turned out to describe how Qpoint already worked, so we wrote it down.

Why: Mark's 2007 thesis on how designers tackle messy, open-ended problems already matched how Qpoint worked, but nothing said so out loud.

Result: The thesis became Qpoint's design method: a written guide, a /method page, a writing rule ("form the problem, then solve it"), a way for AI helpers to read it, and draft marketing lines.

Six of the website's building blocks moved onto the shared shelf.

Why: The website had its own building blocks for marketing pages, like grids, headlines and numbered steps, that other projects could use too.

Result: Six of those blocks moved into the shared kit under two new groups. The website now uses the shared versions, and each block has a live demo.

The app threw out 51 duplicate parts and the design site learned to demo most of the kit.

Why: The app still kept its own copies of parts already in the shared kit, and only 12 of the kit's 43 parts had a working demo.

Result: The app dropped 51 copied files and now uses the shared kit. The design site gained 20 demos, so 32 of 43 parts can be tried live.

The shared parts moved out, and the design site became an honest customer of its own kit.

Why: The style guide was doing three jobs at once: shared parts, brand notes and a website. Its settings needed special switches to know which job it was doing.

Result: The shared parts moved into their own project. The design site now uses them like any other project does, so it feels the same problems everyone else would.

The style guide became the shared kit every Qpoint project borrows from.

Why: Our website and our app each kept their own copies of the same buttons, colors and styles, so every change had to be made twice.

Result: The style guide became a shared kit that other projects plug in with one line. Ten shared parts came first, and nothing in the projects had to be renamed.

A tool that finds the patterns already in use, and the app's first four on the page.

Why: The Patterns page covered only the website. The product app repeats its own combinations across 20 pages, and finding them was all done by hand.

Result: A reusable scanning tool now finds repeated combinations in any project. It found five in the app; four went onto the Patterns page, live and copyable.

Parts started being shown together, the way pages really use them.

Why: Single demos show one part at a time. They don't show how parts fit together, which is how the website actually uses them, over and over.

Result: A new Patterns page shows three common combinations live, each with code you can copy to start a new page.