DEV Community: Ruslan Hrekov

Two Claudes, one app

Ruslan Hrekov — Wed, 28 Oct 2026 05:39:17 +0000

You have Claude Code running in a split tmux pane on your laptop, and Claude open in your browser or phone while away from your desk. Both are working on the same product. Both have access to context, both can draft ideas, and both will happily overwrite each other's work if you don't give them a handshake protocol.

This isn't about running multi-agent swarm experiments with five synthetic personas. It is about the practical everyday friction of developing with AI across two physical devices without losing the plot.

The problem

Context fragmentation is the silent tax of multi-device development.

When you kick off an idea from your phone — a architectural critique, a rough feature outline, or an editorial angle — that session doesn't see your local uncommitted worktree. Meanwhile, the CLI session on your laptop has full filesystem access, the compiler, and git, but none of the conversational nuances you just explored on the phone.

If you paste raw chat transcripts between them, you flood the context window with conversational filler and waste tokens. If you let both edit code concurrently on divergent branches, you spend forty minutes reconciling hallucinated imports and conflicting state schemas.

The model doesn't know what you did across the room unless you write it down in a medium it can read.

What I tried

The temptation is to set up a shared memory sync tool or a cloud pasteboard. I tried keeping an active scratchpad in Notes and pasting blocks back and forth. It failed on the third turn: formatting broke, code blocks lost indentation, and neither Claude knew whether the snippet in front of it was current or superseded ten minutes prior.

Next was branching every quick thought into a remote git branch. That created branch rot: a trail of one-commit branches named feat/nav-idea-mobile and fix/hero-tweak-draft that required manual squashing and dirty git reflogs.

The fix came from treating the handoff like a folded paper note passed between desks.

The protocol

The rulebook that settled the noise:

Role division by device capability. The phone session does classification, critique, and specification. It never writes blind code it cannot run. The laptop session does implementation, execution, tests, and asset generation.
The filesystem is the only shared memory. No ephemeral chat history crosses devices. If an architectural decision is made on the phone, it lands in a spec or a markdown note in the repo (specs/ or memory/). If a learning repeats, it enters DEVLOG.md.
The paper note handoff. When switching contexts, the output of the first session must be an artifact: a single prompt command, a frontmatter block, or a targeted diff. The hero image for this post illustrates the exact mechanic — two devices resting on the desk, with a folded paper note between them.
Preflight verification before merge. Every change, regardless of where the idea originated, must pass npm run verify:numbers, linting, and a local production build on the host machine before any commit lands on main.

What actually happened

This exact post was born through that loop. The editorial direction and prompt were drafted on the fly; the hero image (/blog/two-claudes-one-app/hero-studio.jpg) was generated directly from the terminal via the studio pipeline (node scripts/gen-blog-hero.mjs); and the resulting frontmatter block was handed off cleanly to the codebase without a single token wasted on intermediate conversational chatter.

Zero merge conflicts. Zero context drift.

Lesson

When you collaborate with AI across multiple surfaces, don't try to build a distributed nervous system. Build a mail slot.

Keep the interface between your sessions dead simple: committed markdown for architecture, git diffs for implementation, and single-purpose commands for execution. The model is sharp enough to pick up the thread instantly if the note you hand it has clean boundaries.

Shipping claude-shiploop

Ruslan Hrekov — Fri, 23 Oct 2026 04:15:28 +0000

Every case study on this site runs through the same loop: classify the request, write the spec, build to the spec, measure the result, promote what repeats, forget what doesn't. That loop had a working name — ShipLoop — a one-page protocol in CLAUDE.md, five skills in .claude/skills/, and a scorecard that reads commits, DEVLOG headings, and session logs to measure how often each project actually followed the loop.

Today the whole thing is open source. One line to install into any Claude Code project you work in:

curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash

Repo: github.com/ruslan4427/claude-shiploop. MIT, no sign-up, no telemetry.

Why this exists

Writing clean code with Claude isn't the hard part anymore — the models are strong enough to carry a feature if you point them well. The hard part is the surrounding discipline: catching the request that should be a quick question before it turns into a four-file refactor, keeping a spec/plan/tasks triple so the model can't drift, measuring whether the output actually shipped or just felt like it shipped.

Every project where I eventually built that discipline looked the same at month three: a CLAUDE.md, a DEVLOG, a classifier for inbound requests, a loop that promoted learnings into durable rules. Every project where I didn't build it looked the same at month three too — more tokens burned, more rework, cases where the model wrote a feature I'd already decided to cut.

The point of claude-shiploop is to skip the slow burn. Clone the discipline, measure yourself, delete whatever doesn't fit.

What's in the box

Three things, each independently usable:

The protocol — a nine-lane request classifier (Q, B, S, L, R, T, D, M, O, E) plus a spec-plan-tasks gate for anything above small-feature size. Lives in CLAUDE.md. Takes about two minutes to read. If you only steal one piece, steal this one.

The skills — five entry-point slash commands (/shiploop-start, /shiploop-router, /shiploop-brainstorm, /shiploop-tester, /shiploop-observer) that live in .claude/skills/. Each one is a markdown file; nothing is compiled. You can edit them in place without rebuilding anything.

The scorecard — a Node parser that reads your project's commits, DEVLOG entries, session logs, and git history, and emits five metrics per project: discipline (how many features went through spec-plan-tasks), rework ratio (reverted or amended lines ÷ merged lines), time-to-ship, cost per shipped feature, and tokens-per-ship. All five are explicitly nullable. If the data isn't there, the metric is null, not estimated.

Null is honest

The one rule that holds the whole scorecard together: if a project pre-dates per-project session isolation, or doesn't have the DEVLOG discipline yet, the metric comes back as —, not a number pulled from thin air.

Three of my own seven projects have — in the tokens column. That's visible on /tools right now. The scorecard refuses to fabricate numbers that would make the methodology look stronger than it is, because the first time a null gets softened to "estimated 15k tokens" is the first time the whole table loses its credibility.

The three-tier assignment (naked / self-spec / shiploop) is a human call, documented per project in /tools. It's not auto-detected and it's not pretending to be — that's a judgement about what methodology was actually in play, not a count.

Some rows get numbers. Some get an em-dash. The dash is doing more work than the numbers — it's the promise that the table hasn't been padded.

What the scorecard shows

Across the seven projects I've shipped from this site, two patterns held up:

The discipline column is a floor for everything else. Projects that ran through spec-plan-tasks had rework ratios between 0.2 and 0.6; projects that didn't ranged from 2.0 to 4.5. The ratio of ratios — about ten times less rework when the discipline is in place — survived across different project sizes, languages, and client types.

The time-to-ship column moved the opposite way from what I expected. Projects that spent longer at the spec stage shipped sooner than projects that started coding on day one. The spec time was never visible in the "I'm working" sense, which made it feel slow in the moment. The scorecard made it visible.

Full tables, methodology aside, and the three-tier call for each project: /tools.

The install, one more time

curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash

Supports --dry-run (prints the file-list without touching anything) and --target <dir> (install into a scratch directory for inspection). Reads your existing CLAUDE.md and merges the ShipLoop block in — doesn't overwrite your rules. The install script is 178 lines of bash, no dependencies beyond curl and git, and it's the first file worth reading before you let it run.

Repo: github.com/ruslan4427/claude-shiploop. Issues and PRs welcome.

Classify before you code

Ruslan Hrekov — Sat, 17 Oct 2026 20:47:35 +0000

Every request you send Claude Code looks the same at the API: tokens in, tokens out. But in your project, every request is a different job. One wants a two-line answer. One wants a careful bug fix. One is a new feature that needs a spec first. One is a brainstorm that will burn an hour and leave no code at all.

Running them through the same lane is the most expensive habit I've seen teams keep. A quick question turns into a four-file refactor because nothing told the model to stop at "just answer the question." A bug fix drifts into a cleanup nobody asked for. You see it in the token bill at the end of the month.

The fix takes ninety seconds. You do it in your head before any work starts: pick the lane, pick the model, decide if this one needs a spec. Then begin.

The ten lanes

Straight from the project's CLAUDE.md — the file every session reads first:

Class	Trigger	Action	Model
Q Quick question	"what", "explain", "how does", "why"	Answer directly	haiku
B Bug	"error", "crash", "doesn't work", "fix"	Diagnose → fix → verify → DEVLOG	sonnet
S Small feature	< 3 files, < 1h	Verify spec exists → implement → DEVLOG	sonnet
L Large feature	new screen/service, > 3 files	Suggest Opus → full spec+plan+tasks cycle	opus
R Refactor	"refactor", "clean", "extract"	Analyze → propose → implement	sonnet
T Testing/QA	"test", "QA", "UX", "analyze"	Run the tester skill	sonnet
D Discovery	"brainstorm", "design", "ideas", "how should we"	Suggest Opus → brainstorm skill	opus
M Memory	"what did we", "status", "where are we"	Read `memory/` → answer	haiku
O Observer	"optimize agents", "improve workflow"	Chain-health audit	sonnet
E Expert	"review", "second opinion", "pre-ship check"	Expert subagent + domain capsule	sonnet

That table sits at the top of a protocol file every session loads before the first reply. The classifying happens quietly — what you see is just the lane's action, not its name. But the routing underneath is fixed.

Each lane does one job well. The letter on the bay tells the worker which pattern to follow — same input, ten different outcomes depending on where it lands.

Why ten and not three

Most frameworks I've read squeeze this into three lanes: question / task / big-task. That shortcut is where it falls apart.

Q and B need to stay apart. A quick question wants the shortest answer that clears up the confusion. A bug wants a repro, a root cause, a fix, a verification, and a line in the DEVLOG. Mash them together and Haiku gets handed the bug (slow and risky), while Sonnet gets handed the question (expensive and too wordy).

L and D need to stay apart. A large feature arrives with a destination — "ship the booking flow." A discovery arrives with none — "how should we approach bookings?" The feature lane runs spec → plan → tasks → build. The discovery lane runs brainstorm → spec draft → human decision → then maybe a build. Mash them and you'll get premature code for a question that was still open.

E only shows up if you built the mechanism. The expert lane loads a domain cheat-sheet for your kind of project and reviews against it. If you don't have the cheat-sheet or the subagent, this lane doesn't fire — the request falls back to R or T. If you're starting fresh you can skip E for weeks and lose nothing.

The number isn't for show. Every lane earns its row because the lanes next to it would do the job worse.

Model per lane

The model column is the second half of the pattern, and the one that most directly moves the token bill.

[MetricGrid — see full post]

Haiku on Q and M saves ninety percent on every "what does this file do" and every "where are we on sprint 14." Those are the most frequent lanes by count — pushing them to the cheapest model is the single biggest cost lever in the whole protocol.

Opus on L and D is the opposite move. A deliberate step up to a smarter model when the output will stick around for months — the spec, the plan, the brainstorm transcript. Those documents outlive the session. Paying Opus prices for them is cheaper than paying Sonnet to write a weak spec that turns into three weeks of rework.

Sonnet in the middle is the general lane. It's where most of the keyboard time happens.

The spec gate

The classification feeds one more decision: does this lane need a spec before any file gets touched?

Two lanes do: L and D. Both say it out loud in the table — "full spec+plan+tasks cycle" / "brainstorm → spec draft." Nothing in those lanes gets built until a specs/<N>-<slug>/ folder has three signed-off documents inside it.

Every other lane skips the gate. A quick question doesn't need a spec. A bug fix doesn't need a spec — it needs a diagnosis and a DEVLOG line. A refactor needs a quick proposal in chat, not a sprint folder.

The gate fires only on the heavy lanes because applying it everywhere would be deadly. Picture opening a spec folder for every "what does useEffect do" — the overhead would eat the project. The point is: the discipline matches the weight of the lane.

The lane I keep getting wrong

D (Discovery) and Q (Quick question). These two look nearly the same in the wild and want opposite things.

"How should we approach caching?" sounds like a question. It isn't. It's a discovery — the honest answer wants trade-offs, not a definition.

"What does cache invalidation mean?" sounds similar. It is a question — the honest answer is three sentences and a link.

The signs look the same from a distance. The tell is the walk — one is a short straight path with a bench at the end; the other winds for an hour.

The tell is what the right answer looks like. If the honest answer starts with "it depends on your constraints — tell me about…", you're in D. If it starts with "it's X, which does Y," you're in Q. The question I ask myself: does this want a conversation, or does it want an answer?

Get this one wrong in the D direction and you lose an hour. Get it wrong in the Q direction and you lose a day — because the model is now drafting a spec for a feature you didn't actually want to build.

What this fixes

Across the seven projects on /tools, one pattern held up:

[MetricGrid — see full post]

Roughly ten times less rework when the classifying is in place. That ten-times gap held across every project size I tried — Flutter mobile apps, Next.js SaaS, backend pipelines. The thing that moved the number wasn't the model, wasn't the stack. It was those ninety seconds before each request.

Same tools, same wood, same carpenter. The only difference between the two rooms is whether someone sorted the orders before cutting began.

Time-to-ship moved the opposite way from what it felt like. Projects that classified every incoming request shipped sooner than projects that started typing on request one. The classifying time doesn't feel like progress in the moment — nothing is being built — which is exactly why it was the first discipline to drop whenever I let it. The scorecard made that gap visible.

How to adopt

Shortest path: steal the table.

Open your project's CLAUDE.md, paste the ten lanes word for word, and run the next twenty requests through it in your head. Nothing else changes. No subagents, no spec folders, no new files. Just the one question which lane is this? before every reply. You'll start noticing which lanes you were mixing up.

Full path: install the protocol.

curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash

That installs the classifier, the five entry-point skills, the spec+plan+tasks scaffolding, and the scorecard that measures whether you're actually following the lanes you set. MIT, no sign-up, no telemetry. Repo: github.com/ruslan4427/claude-shiploop. The install script merges into your existing CLAUDE.md without overwriting what's there.

The scorecard that produced the rework-ratio numbers lives at /tools. Seven of my own projects, three tiers, five metrics each. Three of them show — in the tokens column because the data isn't there to count from. That blank is a deliberate rule — the scorecard refuses to guess at numbers it can't measure.

A full write-up of the launch, the install flow, and the "null is honest" rule sits at /blog/shipping-claude-shiploop.

The classifier itself takes ninety seconds per request to run. That's the whole ask. Everything else sits downstream of that one habit.

No company, no API

Ruslan Hrekov — Wed, 07 Oct 2026 05:52:10 +0000

The engagement agent on my SMM Factory pilot does two things while the owner is cutting hair: it leaves conversational comments on in-niche Instagram posts, and it replies to incoming DMs. Haiku writes them, the orchestrator rate-limits them, Playwright drives the browser session that posts them. No approval loop — this is the one path in the system that closes the human loop entirely.

That whole stack is wrong by design. The right stack is Instagram Graph API through Meta Business Suite, with instagram_manage_comments and instagram_manage_messages write-scopes gated behind App Review. The reason I'm shipping on Playwright instead is one gate: Meta Business Verification requires a registered legal entity, and I was running this as a solo pilot without one.

This post is about what that gate actually costs when you can't clear it.

What App Review wants

The public documentation makes App Review sound like a code review with a privacy policy attached. It isn't. For any Advanced Access scope — which includes anything that writes to another user's account — you have to pass Business Verification first. Business Verification wants:

A registered legal entity with a verifiable address.
A DUNS number, or a local-equivalent registration document (incorporation papers, VAT registration, trade license).
Supporting documents on file — a utility bill or bank statement with the business name, matched against government registries Meta cross-references.
A privacy policy published on an active production domain, not a Vercel preview URL.
An explainer video of the exact user flow, demonstrating the scope's use case.

For an incorporated company this is a two-hour admin task. For a solo developer running a two-month pilot it's the whole deliverable, inverted. The gate didn't exist to filter me out specifically; it exists because this is Meta's single most-abused surface, and the business-entity check is a cheap way to make scaled spam uneconomic. By-design is the right word.

Also — there is no sandbox mode for write-scopes. Standard Access gives you read-only testing against your own account. The moment you want to write to a client's inbox or feed, you need Advanced Access, and that path begins at Business Verification. You cannot ship a demo, show it to someone, and then fix the paperwork. The shipping step is the paperwork.

What I shipped instead

A Playwright session with a long-lived IG cookie, driven by two agents:

The publisher uses the cookie to post content on Mondays after a Slack approval.
The engagement agent uses the same cookie to comment on target feeds daily and reply to DMs inline.

Comment landed · heart + thank-you from author

Started a back-and-forth with the owner

Two auto-comments the engagement agent left on in-niche accounts (Prestige Barbershop event · City Barber). Both earned author replies and hearts. This is what the cookie-session fallback actually produces — Haiku-written, Playwright-posted, per-account rate-limited enough to pass as a human reader of the feed.

Haiku generates the text. The orchestrator rate-limits by account and respects an interval floor between actions on the same thread. Everything is logged to Supabase so if an action pattern starts tripping IG's spam heuristics, the ledger can tell us exactly when the pattern changed.

This works. It also has three real costs:

The cookie rotates. When IG issues a new session cookie I have to re-authenticate manually. In the content pipeline logs you'll see this as login_required on the trends endpoint — same mechanism, different scope. For the publisher I rotate on a weekly cadence; for engagement the ambient failure rate is higher because the surface is more active.

It's outside Terms of Service. IG's TOS doesn't make a distinction between a Playwright session with your own cookie and a scraper mimicking your account. If the pattern triggers rate-limit or spam heuristics, the account is paused. The right move at that point is to apologize to the client and accept it, not to look clever.

It won't scale past a handful of clients. Session cookies are per-account. If I'm running engagement for ten barbershops, I need ten cookies, ten weekly re-auth cycles, ten rate-limit windows to coordinate. The architecture is linear-cost in client count; the Graph API path would be constant-cost in the orchestrator and linear only in client API quotas.

What the metrics lie about

The results table on the pilot's case study has one line that reads cleaner than it should:

0 IG violations · 2-month pilot

That's a true number. It's also entirely a function of running under rate limits with one client. If I'd scaled the exact same architecture to five clients, the number would've gone up. If I'd shipped under the Graph API with proper scopes, the metric wouldn't exist — compliance is the baseline, not an achievement.

Any time you see a safety metric reported on a cookie-driven system, read it as a statement about pacing, not architecture.

Should you ship this way?

Depends on exactly one question: are you running a pilot or building the product?

Pilot. One client, two-month window, honest conversation with the owner about where the automation touches their account. Playwright + cookie is defensible. You're testing whether the system is worth the paperwork before you buy the paperwork.

Product. Any plural number of clients, any plan to open a seat on a demo page. Register the entity, pass Business Verification, go through App Review. The paperwork isn't the cost of the API — it's the cost of writing to someone else's account at scale, and it's load-bearing on the whole product's story.

The failure mode is doing a pilot's architecture past the pilot. The cookie that worked for one barbershop in a two-month window is the exact wrong substrate for anything after that.

What I'd do differently

Register the entity on day one, not day sixty. The entity doesn't gate the architecture decisions — I'd still have shipped the orchestrator, the Haiku stratification, the Slack approval, the knowledge-markdown system. What it gates is which API the production version runs against, and that question needs answering before the pipeline is load-bearing on a workaround.

The pilot proved the system can run at cost. The thing it didn't prove — because the paperwork wasn't done — is whether the system could run at scale legally. Those are two different questions and I conflated them for most of the pilot.

The clean API wasn't a lie. It was a filter, pointed exactly at builders like me, working exactly as designed.

Shipping the cross-poster

Ruslan Hrekov — Thu, 01 Oct 2026 04:37:52 +0000

The previous post promised cross-posts to LinkedIn and dev.to "once Sprint 14 wires the automation." Three days later, Sprint 14 shipped and you're reading proof — this post landed on both platforms through a cron job the site runs on itself.

Here's what shipping that pipeline looked like.

The itch

Cross-posting manually dies at the third post. Open LinkedIn, strip the markdown, re-check character count, paste. Open dev.to, remember the canonical URL field, paste the body, slugify the tags, confirm. Each post is fifteen minutes of friction between "I wrote something" and "the people who follow me on those platforms can read it." After two tries you stop writing instead of fixing it.

The fix had to clear a lower bar than you'd think: it had to work, land in the correct places, and not accidentally publish the same post twice. The rest is polish.

The constraint

One decision gated everything: no dedicated service, no Zapier, no VPS. The site already deploys on Vercel and the code already lives on GitHub, so the pipeline had to live inside the repo. GitHub Actions free tier cron, scripts in the same language as the site, state in a committed file. If the cron ever misbehaves, I want git log to tell me when and why.

That ruled out LinkedIn's partner-reviewed Community Management API (multi-week approval gate for a solo-developer app) and ruled in the self-serve w_member_social scope targeting the legacy /v2/ugcPosts endpoint. Different surface, same posting outcome.

The pipeline

Three hundred lines of orchestrator (scripts/publish-due.mjs) read content/blog/schedule.yml, cross-reference .distribution-ledger.jsonl, and when a scheduled post is due and not already published, hand it to the matching publisher — lib/distribution/devto.mjs or lib/distribution/linkedin.mjs. On success, three things happen in a fixed order:

Append to the ledger ({slug, channel, publishedUrl, remoteId, ts})
Mutate the post's frontmatter (status: posted, publishedUrl, postedAt)
Commit and push with [skip ci] so Vercel still rebuilds but the cron origin is filterable in git log

The ordering is non-negotiable. If step 2 crashes, step 1 already recorded the publish — the next cron tick sees the ledger entry and skips the slug instead of double-posting. Reversing to frontmatter-first means a crash leaves the post un-marked-as-published; the next tick re-publishes.

The ledger is checked into git. Had to catch that one in review — my first draft had .distribution-ledger.jsonl in .gitignore because the filename looks like local state. GitHub Actions runners are ephemeral; an ignored ledger would see empty state on every tick and re-publish every past-scheduled post. The file isn't local state; it's the durable idempotency guard.

The three traps I almost shipped

/rest/posts vs /v2/ugcPosts. The LinkedIn docs lead you to the newer /rest/posts under Community Management API. Looks modern, has nice typed schemas. Returns 403 with a self-serve token because that surface is partner-review-gated. The legacy UGC endpoint with X-Restli-Protocol-Version: 2.0.0 (and no LinkedIn-Version header) is what self-serve apps actually get. A full afternoon vanished before I noticed the two docs sets live in parallel universes.

Refresh tokens don't exist on self-serve. The access token is sixty days. The weekly refresh worker I wrote assumed a refresh token would arrive — none did. Not a bug; an empirical limit of the w_member_social scope. Fix was a graceful no-op with a cliff-countdown warning, and a calendar reminder two weeks before expiry to re-run the OAuth handshake manually.

Company Pages aren't optional, but they're one-time. My app wouldn't bind to a personal profile; LinkedIn's post-2019 verification chain wants a Page as the ownership anchor. Created a minimal Page in fifteen minutes, bound the app, then never used the Page again. All posts go to the personal profile via urn:li:person:XKuTKDehCv.

What runs now

Hourly on 15 * * * *. Twenty-one seconds end-to-end on a cold GitHub Actions runner. On ticks with nothing due, the output is one line — [publish-due] nothing due at <iso-timestamp> — and the job exits clean. On ticks with a due post, you see the publish lines, the devlog entry, and a cron commit landing in main.

The first live run shipped the previous post, Launching the journal, to both platforms. That post went live manually because I needed to validate the renderers against real APIs before trusting the cron. This post is the first one going through the full automated path — authored, scheduled, pushed, published by the machine, with a commit back on main to prove it.

What this post itself proves

You're reading a Build Log about a cross-posting pipeline. If you found it on dev.to or LinkedIn, that pipeline is what put it there — the schedule-driven path with no manual step between my git push and your scroll.

The whole thing is in the open: three hundred lines of orchestrator at scripts/publish-due.mjs, four invariants locked into STABLE_LOGIC.md, the full ship retro at DEVLOG.md. Clone the repo, read the cron, run the dry-run — the pipeline isn't a demo of a clever idea, it's the thing that made this very post appear in two more places than I had to type.

Launching the journal

Ruslan Hrekov — Thu, 01 Oct 2026 02:27:51 +0000

The site had five case studies and no place to put anything shorter. Everything I wanted to write about — a debugging trace, a pattern that keeps paying off, a skeptical read on a tool the timeline is excited about — needed the same weight as a full case study or it got dropped. That's the wrong shape.

What this is

/blog supports four formats:

Case Study — long-form, receipts attached, commit hashes referenced.
Build Log — chronological, dated, mid-work. This post is one.
Field Note — skeptical take on something popular. Short, arguable.
Pattern — a rule I keep applying, why, and when it breaks.

Each post lands with reading time, tags, and (where relevant) a Receipts aside — links to the actual commits, prompts, or artifacts behind the claims. If I can't cite it, I don't write it.

Under the hood

MDX with frontmatter validated at build time (invalid frontmatter throws).
/rss.xml is generated from the same source with CDATA descriptions.
Google Search Console meta tag ships via env var, so the feed shows up.
Analytics: GA4 with IP anonymisation, off by default for EU visitors until you click accept. proxy.ts (Next.js 16's edge middleware convention) reads Vercel's x-vercel-ip-country header and sets a geo-eu cookie so the client knows which path to render.
No third-party tracking beyond that. No newsletter form yet.

What's next

First real posts land over the next two weeks — one Field Note on prompt patterns that stopped working when I moved from Sonnet to Opus, one Build Log on Sprint 11 itself, and a Pattern write-up of STABLE_LOGIC.md (the file that keeps AI collaboration from unwinding your own fixes).

Subscribe via RSS, or wait for the LinkedIn + dev.to cross-posts — Sprint 14 wires the schedule-driven automation that lands this very post on both platforms.