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.oneGA4 property to its Search Console property - linked the
rankwar.appGA4 property to its Search Console property - kept
lmachine.fyiintentionally 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.oneandhub.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.appresolves to the discovery feed*.rankwar.appresolves 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
vendorornode_modulesfrom 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 installinside 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.