Cycle Tours

A cycle leaves a lot of record behind: CYCLE.md, plans, reviews, captures, sketches, a story, and pages on the site. Someone who wasn't there, whether Mark coming back to it, Tyler, a build partner or an agent, needs a way through all of that. The site already generates the pages for it. What we don't have yet is a repeatable way of walking someone through them.

We aren't writing that down in advance. Mark asks for tours of a few recent cycles, the agent gives them, and we note what landed.

Open-ended by Mark's direction. Each tour adds a field note below. The cycle closes when the notes show a shape stable enough to write as a skill, either a new /cycle-tour or a mode of /tour, or when Mark calls it.

Questions we're watching:

1. The medium. Chat narration beside the browser pane on the live site, localhost while the deploy lags, or the c125 tour layer (TourHost rings and callouts, the qpoint-guide MCP) driving the cycle pages.
2. The order of stops. Story first (c124), or the shape (c130's sketch), or the visual record, and how much of the raw record to open.
3. What a tour is for. Orientation, a review stop, a handoff, or catching up on a week.
4. What a tour turns up. Gaps in the generated pages (missing story, stale capture, a doc link that doesn't prerender) are findings for c124 and c130.

In: tours of the cycles Mark names, field notes, small fixes to the cycle pages when a tour shows one is needed, and the skill draft once there's a pattern.

Out: rebuilding the cycle pages, and extracting the tour layer to q-nuxt-layer (c125 W-packages own that).

• kick-off (2026-11-12): opened from Mark's prompt. The site was deployed so the tours run on live pages.
• deploy (2026-11-12): npm run deploy took the live site from 4d222f49 (built 02:31Z) to 416de93c6a plus 19 uncommitted files, built 16:02Z, layer 0.9.37. The live _deploy.json on design-f39.pages.dev confirms it. c142's cycle page and c133's pages answer 200. The c133 scene gallery landed after the build started, so it ships with the next deploy. The build logged two errors that don't stop it. (1) EISDIR on /api/trainings: the list and the per-training files share a path, so the static site serves /api/trainings/T-MCP-1 but the list returns 404. c133's publish.md names the list as what the apps read, so that's c133's to settle before release (the plane copies the JSON in at release, D29). (2) A fatal 404 prerendering /cycles/evolution/native/app-status.
• second deploy (2026-11-12): built 16:10Z, live on design-f39.pages.dev. The scene gallery is live. Rob Genova's credit and the thread below came after the build.
• documents-and-work (2026-11-12): from the c133 tour, Mark asked for a more prominent documents section that can be linked to directly, and a terse summary of work (micro-problem → resolution, with the attempts) (prompt, plan). Built on every cycle: a Documents tab at /cycles/<project>/<id>/docs, and a Documents section on the story (#documents). It covers every document with its first heading as the title, grouped, plus the pages the captures came from. Built where a story writes one: a "Summary of work" (#work) under In short, with c133's twelve lines as the first. Checked on :3000 at 1440 and 375 (c133 story and tab, c142 with no story); no failed requests after a reload. Four open questions in the plan.

One entry per tour: the cycle, the URLs walked, the order, what went well, what didn't, experiments and whether they paid off.

Tour 1: c133 Remediation Training (2026-11-12)

The ask: "walk me through the lesson file structure, and where are the illustrations coming from?" This was a tour led by two questions, not a whole-cycle tour.

Medium: localhost:3000 in the browser pane, with the narration in chat. The deploy was still running, so nothing ran on the live host yet.

The walk:

1. /cycles/design/c133, the story, to orient. Change 2 ("a new lesson is a file of sentences and questions, not a new screen") is the question in one line.
2. /pages/phase4/trainings, the preview page. It shows the collection as the parser reads it: per file the steps with their scenes, the questions with the step each checks, the slots, the voice result and the hash. This page is the file structure drawn.
3. /pages/phase4/mock/training?findingId=F-G&at=lesson, a lesson with its scene drawn on a real finding. ?findingId= and ?at= land the tour on the exact state.
4. For depth, the source: authoring.md (the format table), en/secrets-in-prompts.md, scenes.ts, components/training/scenes/*.vue.

What went well: the cycle's own generated pages answered both questions without opening the raw record first. The deep-link knobs (?findingId, ?at) make a tour stop exact, and authoring.md already had the table a tour needs.

What didn't: no page shows the twelve drawings together. The preview page's Scenes section is a table of names and descriptions, so "where do the illustrations come from" needs a lesson opened per scene. The pane's default viewport is 800×600, which squeezes the lab shell.

Pattern to keep: a question-led tour picks its own stops: story → the lab page that draws the structure → one state deep-linked → the source last.

What the tour fixed (same day, on Mark's yes): the preview page's Scenes table is now a gallery. Every scene is drawn on a real finding and links to its step. Drawing them together turned up a layout bug the single-lesson view hid: sanctioned-list overflowed its figure at mid-width viewports. Recorded in c133's Key Changes. Lesson for the mode: a tour that can't show something in one look has found a missing page, and building it is a cheap way to find more.

Credit surfaced (same day): once the gallery was up, Mark named Rob Genova's informational drawings in two Qpoint blog posts, The Hidden Agent Surface and Your Agents Need a Dynamic Sandbox, as the scenes' inspiration. The site credits both posts to the Qpoint Team, so the record wouldn't have found it. Rob is now credited in c133's Lineage, authoring.md § Scenes, under the gallery's heading, and in c133's story (Thanks to, plus a "scene-gallery" change). Pattern to keep: a tour is a good moment to ask "where did this come from?", because the guide sees the work beside its sources and the person remembers what the record left out.

Tour 2: c133 again, "how much of it is ready to be merged in?" (2026-11-12)

The ask: a status question, not a structure question. The answer needed three sources the cycle page doesn't put side by side: git (committed, pushed, branches), the hand-off's "whose is what", and the receiving repos (qnative, c134, market-analyst).

The walk: git on design (every c133 commit is on main and pushed; only today's tour edits are local) → handoff.md (what each receiver takes) → review-5.md (the calls and what waits on others) → the receivers. qnative has the message types, and Start training answers "not on this build yet". c134 has no plane repo yet: Phases 1–5 wait for Tyler's repo decision and Kamal. The brief's PR had merged.

What it found: the record was stale on one fact. The brief merged on 2026-11-11, but three places still said in flight, so the "waiting on" list was wrong. Corrected in c133.

Pattern to keep: for "is it ready", split the answer by destination: design main, each receiving repo, and the decisions still owed. Check every "waiting on" item against its source, because a pickup line ages faster than anything else in the record. A readiness view (merged · ready to port · blocked, and on whom) is a candidate section for the cycle page, beside the summary of work.

Tour 3: walking c133's seven Phase 5 calls (2026-11-12)

The ask: "Yes, walk them", straight after Tour 2 named Mark's calls as one of the blockers. The tour turned into a review stop.

Medium: the thinnest case open in the pane (Secrets in prompts from the library, 2 of 4 steps). The calls went as two batches of multiple-choice questions (4, then 3). Each question stood on its own, with the proposal first and the alternatives from review-5.md.

What went well: seven calls ruled in two exchanges. Mark ruled two against the proposal. His free-text note on call 3 (a high self-taken count shows a strong posture) changed call 5's options before he saw them, which is why calls 5–7 went in a second batch instead of all seven at once. The rulings went straight into the record as D38–D44: plan.md, review-5.md § Ruled, CYCLE.md, and the story's decisions and pickup.

Pattern to keep: when a tour reaches a review stop, put the thinnest case on screen and ask in batches small enough that one answer can reshape the next. Record the rulings in the same turn. A tour that ends in decisions is worth more than one that ends in a summary.

What followed: Mark had this session build c133's Phase 6 rather than hand it to a new one ("Do this task here"). It's committed locally as e0167ff580, at c133's own review stop (review-6.md, five calls). So the loop ran tour → readiness → rulings → build → the next review stop, without leaving the session. Worth noting for the skill: a tour can hand off into work when the person rules on the spot, and the session that gave the tour already holds the context the build needs. The loop ran once more the same day. Phase 6's five calls were walked the same way (two batches; call 5 split into four parts) and ruled as D45–D51, and Phase 7 (the first topic training, Observe and Enforce) was built and committed as 712f08588f. Another session (c143) pushed e0167ff580 along with its own work.