Bring All Boats To Level
N Apps → One Parity Plan
A cross-app leveling process — a plan-maker, not the work:
Ed!
I have a job!
We have been updating the three apps- email, calendar, and contacts, separately, and have made different amounts of progress in each one, with various UI and functionality upgrades made to each. With some of them, like design decisions, I've tried to have them apply globally when I make them, but I don't think that's the case with EVERY thing I've done, so what I want to do is to look at the work that has been done to the three apps, make a list of features (we have a system for that), make a list of all the design things we've done (like apply colors to things, or made design decisions), and then I want to look and see if there are any ways to apply any of them more broadly.
Say, for instance, that I applied a color scheme to different calendar types in the calendar app- would that color scheme also be useful in the contacts app, or the email app, or any other app that is currently in the forest?
Maybe we implemented a new drag and drop pattern in the calendar program and the header bar- is there anywhere in the contacts or email app where it would make sense to apply the drag and drop system?
I think you get the gist.
It's basically a process that you look at the design and capabilities of N apps and then figure out ways to bring all the boats to the same level- to make everything more integrated and to make the capabilities more universal, both in pattern and how they are built, but also, as it follows, in how they feel to the user.
I imagine we would want to be stepwise about this, so we first run the capabilities and features report, which, again, we have.
Then we need to be able to look at that list and see where the gaps are- where are the places where we need to fill in so we have a solid consistent wall of features and design across the entire forest.
We need to fold this in, obviously, to our Work Hierarchy system, and the design and brand plans, as all of that needs to be super integrated, stitched, tuned, and seated. We need compliance gates and verification- we have ALL the tools we need to build this already.
What I would like is for this process to do ALL of this stuff that I've laid out, and then kick out a final Recommendation Report (pick a better name), with a very well defined work plan set out for how to do all the work- use Work Orders and chunking and think in blocks and Block^N here. So again, this whole process that we are building and formalizing will NOT be doing the work- just creating how the work will be done. Also bake in an automatic full Self Review before the plan is presented to the operator.
Make sure ALL the documents created along the way are also part of the final presentation package.
Can you make this thing super deterministic, and use computer-run scripts wherever possible? How much of that can we offload from LLM to scripts and other code tools?
Please run the Kindling program on this, don't blackbox and don't compress- I want to see all the deliberations. Make ALL the docs you need to here- RCR deliberations included- and run everything heavily to-spec. Get Crux in on this, and Wes- make sure we have lots of FWW(C) rolling around deliberations.
Speaking of heavy, also load up heavy with *X, and know what that means.
Kick me out a V1 plan for what this could look like- what would it look like and how can we build it. And obviously your work here is to generalize this thing as much as you can so we can use it all over the place. This is a MEGA helpful tool, so let's do it right.
— Shea Gunther · operator drop, 10.2006
A stated aim that shipped — the Chalk Line: it folds N sibling apps into a Parity Matrix, finds where each app is behind its siblings, and emits a Block^N work plan — a plan-maker, deterministic where it can be, that does not itself do the work.
The problem is drift: email, calendar, and contacts were built separately and made different amounts of progress, and design decisions that should have applied globally didn't always. The operator wants a process — explicitly not the work itself — that reads the design and capabilities of N apps and finds where something from one belongs in the others: a calendar color scheme that would help contacts, a drag pattern that belongs in email too.
The shape is stepwise and deterministic: run the capabilities-and-features report, find the gaps against a “solid consistent wall of features and design across the entire forest,” fold it into the Work Hierarchy and the brand plans, gate and verify it, and kick out a work plan in Blocks and Block^N with an automatic Self Review before it reaches the operator. “Can you make this thing super deterministic … how much can we offload from LLM to scripts?” It shipped as the Chalk Line.
The wider frameThe prompt that became the Chalk Line. Three apps — email, calendar, contacts — were built separately and drifted: features and design decisions landed in one but not always the others. The operator wants a process (not the work itself) that reads the design and capabilities of N apps, finds where a color scheme or a drag pattern from one belongs in the others, and brings all the boats to the same level — folded into the Work Hierarchy, gated and verified, deterministic with scripts wherever possible, ending in a well-defined work plan in Blocks and Block^N. It shipped as the Chalk Line: a cross-app harmonizer that folds N sibling apps into a Parity Matrix and a Block^N plan.
“bring all the boats to the same level- to make everything more integrated and … more universal” — The goal named in one image: level the fleet. A feature or design decision in one app should propagate to every app where it fits.
“this whole process … will NOT be doing the work- just creating how the work will be done” — The critical boundary: the Chalk Line is a plan-maker, not a builder. It emits the work plan; the building is a separate line.
“Can you make this thing super deterministic, and use computer-run scripts wherever possible?” — The determinism-first demand: push everything that can be a script out of the LLM and into code — the reason the Parity Matrix is a byte-fold, not a judgment call.
The prompt is written in the working vocabulary of the methodology. Here is what the shorthand means:
- Work Hierarchy
- The system's structure of work — lines, campaigns, and the backlog that hangs off them — that cross-app work has to fold into.
- Block^N
- Scaling the Block Principle across many parallel items at once — the same named-blocks-and-joints discipline applied N-wide.
- Work Orders
- Self-contained task packets dispatched to a worker instance — one instruction plus its materials, sized so identical tasks batch into one.
- Kindling
- A Loop MMT program that keeps the deliberation visible — “don't blackbox, don't compress” — so the reasoning is shown in full rather than summarized.
- *X / ∗X
- A reflex-sweep instruction: load the review sweeps heavily before a load-bearing move. “Load up heavy with *X” means look at everything first.
- Stitch
- An integration-assessment pass — check how a new piece composes with what's already around it.
- Tune
- A cohort-alignment pass — bring a set of related things into consistency with each other.
- Seat
- The post-build integration step — wire a finished thing into the registries, memory, and companion docs so it's actually in place.
- Crux
- The Dev Crew's first-pass line-finder — the named hand who reads a problem's line and finds its crux move, as distinct from the advisory board.
- Wes
- A board member whose lens is chaos and complexity science; asking for Wes means run the session in a playful, exploratory register.
- FWW(C)
- “Fun, Whimsy, and Weird (and Chaos)” — the methodology's rule that play and surprise are load-bearing, not decoration.