Build log Mar 21, 2026 2 min read

Day 005 - linking Search Console and turning RankWar into a first-class monolith surface

Day five of the lmachine monolith: both GA4 properties were linked to Search Console, RankWar gained real monolith-native public surfaces and join mechanics, and the repo learned the correct way to run parallel Laravel worktrees without fake speed.

What shipped today

  • linked the lmachine.one GA4 property to its Search Console property
  • linked the rankwar.app GA4 property to its Search Console property
  • kept lmachine.fyi intentionally out of GA because redirect traffic is fake signal
  • shipped the public RankWar discovery surface and wildcard campaign surfaces inside the Laravel monolith
  • shipped the monolith-native RankWar join flow, referral scoring, and leaderboard queries with Pest coverage
  • tightened the repo-local worktree rule for Laravel so future agents stop faking speed with shared dependencies

The dominant analytics move

The weak move is to treat Search Console linking like admin trivia.

It is not trivia.

If the search surface matters, then:

  • GA must exist on the real production hosts
  • Search Console must point at the same truth
  • redirect domains must stay out of the dataset

That is why the right split remains:

  • one GA property for lmachine.one and hub.lmachine.one
  • one GA property for rankwar.app
  • no standalone GA property for lmachine.fyi

Anything else muddies attribution and turns search data into vanity noise.

RankWar is now a real monolith surface

The migration stopped being a future tense exercise.

Inside the monolith now:

  • rankwar.app resolves to the discovery feed
  • *.rankwar.app resolves to campaign war rooms
  • join events create shared contacts under the same database spine as the rest of the portfolio
  • referral rewards and leaderboard state live in explicit rankwar_* tables

That means the migration line is now clear:

  • the narrative surface exists
  • the data model exists
  • the auth spine is shared

What remains is import, creator tooling, and cutover discipline.

The real worktree lesson

Parallel worktrees are leverage.

Fake worktrees are not.

The losing pattern was:

  • create a fresh Laravel worktree
  • symlink vendor or node_modules from another checkout
  • pretend that means “instant velocity”

That breaks bootstrap and makes the next agent inherit garbage.

The correct rule is:

  • one dedicated worktree per lane
  • one writer per worktree
  • run composer install inside that worktree
  • create a local .env
  • run the smallest Pest suite that proves the lane

That is the difference between real parallelism and distributed sloppiness.

Why this matters

This repo is not trying to become a collection of disconnected apps.

It is trying to become the reference case for:

  • one Laravel monolith
  • many domains
  • one shared identity spine
  • coding-agent-driven operations from browser to server to provider dashboard

That is the game worth winning.