**Slice:** the felt experience. operator dignity audit.
> Architecture is downstream of trust. If the operator can't tell whether the system is working, the system isn't working — even when it is.
---
### Ewing on a Sunday morning (Claude Desktop, MacBook, kitchen table)
> It's 7:42 AM. Coffee's hot. I told Claude Desktop to draft a teaser for the Capstone deal using the `draper` skill. The output comes back and something's off — the "Banned Words" list is missing "synergistic." I added that to the skill on Friday. I know I did. I'm staring at this output that quietly used the OLD version of my own skill and I'm thinking: how many other documents have I sent out this week that were generated against a version of myself I already retired? I don't know. That's the thing. I don't know. I came here to draft one teaser and instead I'm git-log'ing my own skills folder on a Sunday. The whole point of the system is so I don't have to do this.
### Charlie at hour 3 of his shift (intern, Meetings page)
> The README says "use the `transcript-extractor` skill on the Fireflies row." I type that and Claude says it doesn't see that skill. I look at the path the docs gave me. The folder exists, but it's empty. I check the slack channel — nothing. I don't want to ping Ewing because it's 11 AM on a Tuesday and he's on a buyer call. I don't want to ping Bear because he'll know I don't know. So I sit. I rebuild the prompt manually from what I remember the skill does. It takes me 40 minutes. The output is okay. I ship it. I never tell anyone the skill was missing. Three weeks from now Ewing will say "why does our transcript output look different from the skill template?" and I won't remember this Tuesday at all.
### Bear after a fresh laptop setup (third week, Deals page)
> Fresh M2 from the Apple Store. I follow the setup doc. `git clone next-chapter-os`. `bash setup.sh`. Green checkmarks. I open Claude Code and type `/skill-loader`. It says "ALWAYS ACTIVE" — already loaded. I think that's good. I run my first deals task. It works. So far so good. Two days later I notice the `deal-awareness-protocol` skill on my machine is dated April 28 but Charlie mentioned a tweak Ewing made on May 4. I check my repo — it's clean, no pending pull. So is the skill stale, or did Ewing's tweak just not happen yet? I don't know which side is wrong. I don't want to be the intern who breaks his machine on day 17. I just don't use that skill today and route around it. The doubt arrived before any error did.
---
For each hard constraint, the **specific moment** an operator either trusts the system or stops trusting it. If that moment doesn't produce a clear signal, operators will manually verify — and manual verification is the bug we're trying to kill.
| # | Constraint | The moment of trust (or its loss) | |---|---|---| | 1 | **Push, never pull** | Ewing edits a skill on his MacBook, commits, pushes. Three minutes later he opens Claude Desktop and asks for the same skill. **Trust forms** if the new behavior is visibly there — referenced banned-word, new section heading, anything observable. **Trust dies** if the only way to know is to `cat` the skill file. The signal must be in the *output*, not in the filesystem. | | 2 | **Near-real-time** | First time after rollout that Ewing pushes a fix during a live deal call. He needs the skill to be current on Charlie's machine in Charlie's next prompt — measured in the same conversation, not the next workday. **Trust forms** when Charlie's output reflects the change without Charlie being told to do anything. **Trust dies** at the first "did you pull?" message in Slack. | | 3 | **Every surface** | Three sessions opened in three places (terminal, Desktop, Cowork) on the same morning. Same skill named in all three. **Trust forms** if all three return identical structural output for the same prompt. **Trust dies** the first time two surfaces disagree about a banned word — because that's the moment Ewing realizes "current" means different things on different machines. | | 4 | **Conflict-safe** | An intern accidentally edits a skill locally to fix a typo on their own machine. The next push from main must not silently overwrite their unsaved work, AND must not silently leave them on a fork. **Trust forms** when the system says "you have a local edit to `draper/SKILL.md` — open a PR or discard?" in a place the intern actually sees. **Trust dies** when the answer is "your change is gone, no notice, no diff." | | 5 | **Onboarding-trivial** | Bear's first morning on a fresh laptop. He logs into his GitHub, clones the repo, opens Claude Code, types one command — any command — and his skills work. **Trust forms** if there is zero conditional logic in his head ("did I run the symlink script? did I install Doppler?"). **Trust dies** the first time he has to read a setup doc longer than five lines. | | 6 | **Self-healing** | Charlie's machine drifts because his auto-pull hook errored at 6 AM Tuesday during a flaky wifi moment. The system detects this within minutes, repairs without Charlie typing anything, and either tells him "I caught a drift and fixed it" or stays silent if it succeeded fully. **Trust forms** when there's a visible Slack ping to Ewing on every detected drift, even self-resolved ones — because Ewing needs to see the system *catching* things, not just claiming to. **Trust dies** the first time someone discovers a four-day drift after the fact. |
Each row's load-bearing word: **observable**. If the operator can't observe the system working, the operator builds a private manual-verification ritual. That ritual is the thing we're trying to remove.
---
1. **The deal-room embarrassment.** Bear ships a deal memo using stale `draper` output (the version before Ewing pruned three banned phrases). The memo includes one of the banned phrases. Buyer's analyst points it out in front of Ewing on a call. Ewing learns about it from the buyer, not the system. **Damage: trust + reputation.** This is the worst case because it's external-facing and Bear doesn't know he was set up to fail.
2. **The skill that never showed up.** Ewing edits a skill on the MacBook. Push succeeds locally. The fan-out webhook fails silently (signed cert expired, GitHub Actions runner offline, whatever). Three days later Ewing notices the change isn't propagated. He's now spent three days under the assumption that interns were running the new version. Every output during that window is suspect. **Damage: retroactive uncertainty across 72 hours of work product.**
3. **The "just works" lie.** Charlie's machine appears to be in sync because his last successful pull was four hours ago, but a skill was *renamed* between then and now. Old skill file still exists. New skill doesn't. Charlie's sessions reference the old skill by its old name without error — they just produce subtly different output. He never knows. **Damage: trust in the *concept* of "skills are current," because once you find this case, you stop believing any "in sync" indicator anywhere.**
4. **The Sunday morning trap.** Ewing pushes a skill change Saturday night. Mac mini's LaunchAgent is set to pull every 5 minutes during weekday business hours only (cron quirk no one remembered). Sunday morning Ewing tests on his own machine — works. Charlie shows up Monday at 9 AM, his machine pulls successfully, all good. But the Mac mini ran two automated overnight jobs Sunday night using the OLD skill, generating two outputs Ewing now needs to find and re-run. **Damage: hidden work product corruption Ewing has to clean up.**
5. **The drift-during-leave scenario.** Charlie takes a four-day weekend. His laptop is closed. Skills change six times during those four days. He opens his laptop Monday morning and starts working before any sync runs. First three prompts use stale skills. He's confident, fast, productive — and wrong. **Damage: the system's worst failure mode is highest-velocity work.**
6. **(Bonus) The notification firehose.** Architecture team over-corrects from #1–5 by emitting a Slack ping every successful sync. Within a week, Ewing mutes the channel. Within two weeks, the one ping that mattered (a *failed* sync) gets buried in 800 successful pings. **Damage: alert fatigue, leading right back to silent failure.** Including this because it's the failure mode of the obvious fix.
---
What "onboarding-trivial" must literally look like:
00:00 Bear opens his new MacBook for the first time.
00:05 Logs into Apple ID. Logs into 1Password.
00:15 Opens Terminal. Types: gh auth login. (One command. He knows this one.)
00:25 Browser pops, GitHub OAuth, click approve.
00:30 Types: gh repo clone next-chapter/next-chapter-os && cd next-chapter-os
00:45 Types: ./bootstrap ← single word. no flags. no doppler dance.
00:50 Script does its thing in the background while showing a single progress line.
00:58 Script prints: "ready. open Claude Code."
01:00 He opens Claude Code. Skills load. Done.What he does NOT see, ever: - The word "symlink" - The word "Doppler" (it's already authed via 1Password SSO) - A README longer than five lines - A choice between "yes" and "no" he has to make - Any indication that something might be different on his machine vs. Charlie's
The competence-vs-stupidity inflection point lives at **00:45**. If `bootstrap` fails or stalls, Bear is stupid. If `bootstrap` succeeds without him understanding why, Bear is competent. The architecture's job is to make `bootstrap` succeed without explanation — not to teach Bear what's happening underneath. That's the whole point.
There must be **zero conditional steps** in the doc. Every "if you're on Apple Silicon, do X" is a paper cut that adds up to "I don't think I did this right."
---
1. **The achievement-unlocked notification.** Solving real-time sync by emitting a desktop/Slack notification on every successful skill update. *Looks* like trust-building (you see the system working). Actually anxiety-building: every notification is a context switch. Within two weeks operators silence the channel and we're back to silent failure with extra steps. **Analogous failure:** Dropbox's "file synced" notifications circa 2014, which everyone disabled, after which Dropbox lost the only signal users had that sync was working at all. **Fix:** notify only on *failure to sync within SLO*, never on success.
2. **The "are you sure?" confirmation dialog.** Solving conflict-safe by prompting the user before any local change is overwritten. Sounds responsible. In practice the dialog fires during normal operation (a stash that resolved cleanly, a non-conflict edit), users learn to dismiss it without reading, and the *one* time it actually matters they click through reflexively. **Analogous failure:** browser certificate warnings — clicked through 99% of the time because they're shown 99% of the time on legitimate sites. **Fix:** never dialog on the happy path. Only intervene when there's a *real* divergence detected (file hash mismatch on a tracked path), and intervene by *creating a PR*, not by blocking the operator.
3. **The dashboard.** Solving observability by building a Vercel page at `/skills-status` showing every machine's last sync time, last commit, drift state. Sounds great. Will be checked exactly twice — once when launched, once when something breaks. The other 363 days a year it provides a false sense of monitoring because nobody is looking. **Analogous failure:** every status page on every internal tool ever built — they exist to make engineers feel they've shipped observability without anyone actually consuming the signal. **Fix:** push critical signals into Slack DM to Ewing on the failure axis. Don't build a page that only matters when someone remembers to look.
---
Six months from now (November 2026), the system respects operator dignity if and only if **the phrase "did you pull the latest skills?" appears zero times in Slack between any two operators (Ewing, Charlie, Bear, Mac mini DM thread)**. Not "rarely." Zero. Searchable, measurable, falsifiable. The presence of that phrase is the canonical symptom of the failure mode this entire architecture exists to eliminate — when operators feel responsible for verifying state the system claims to manage, the system has not earned their trust regardless of how technically correct it is. The corollary signal: number of times any operator opens a `SKILL.md` file just to *check what version they have* should also trend to zero, measurable by terminal history audit on a monthly cadence. If both are zero at six months, dignity is intact. If either is non-zero, the architecture failed even if every webhook fired successfully every time.
---
The skills-sync architecture must be designed for *observable trust* before it is designed for technical correctness. Operators (especially Charlie and Bear, who lack standing to debug) build private manual-verification rituals the moment they cannot tell whether the system is working — and those rituals are precisely the failure mode the project exists to eliminate. The load-bearing word is "observable": every constraint has one specific moment where trust is built or lost, and the architecture must produce an unmistakable signal at each of those moments without descending into notification firehose. Silent successful failure is the worst outcome and ranks above broken-and-noisy.
I cannot verify what Charlie and Bear *actually* do when they hit a missing or stale skill — I'm reasoning by analogy from intern behavior patterns in general (defer to peer, defer to manager, route around silently). I have no Slack-thread or transcript evidence from Next Chapter specifically that interns route-around-and-don't-tell-anyone vs. immediately escalate. If they actually escalate every time, persona #2 is wrong and silent-failure entry #1 is overstated. The architecture would benefit from a quick listener-driven retrospective on the last three "stale skill" incidents to confirm the route-around-silent hypothesis, but that's outside my Phase 1 scope.
This run resembles run #013 (os-tab-audit) where the load-bearing finding was that "the OS is a deal machine dressed as a developer dashboard" — i.e., the human-experience layer was the thing nobody was solving for explicitly. Same shape here: skills-sync is being framed as an infrastructure problem, but the actual failure mode is felt-experience (dignity, doubt, silent shame). Also resembles run #017 (about-us-pdf) where my Phase 1 work flagged that two agents were producing parallel content streams without selection ownership — that's the same pattern as #5 in my anti-patterns list (status dashboard nobody owns reading).
When asked to assess infrastructure architecture in future runs, my old response was to describe what users feel when the system breaks. Now I will lead with the *moment of trust-or-loss* per stated constraint and produce a falsifiable six-month dignity signal, because abstract empathy-talk doesn't constrain architect's decisions — a specific observable moment does.
Generated from 019__draper.md — do not edit this HTML directly.