Known Surprises
This file tracks repository-specific confusion points that caused agent mistakes.
Entry Criteria
Add an entry only if all are true:
- It is specific to this repository (not generic advice).
- It is likely to recur for future agents.
- It has a concrete mitigation that can be followed.
If uncertain, ask the developer before adding an entry.
Entry Template
### [Short title]
- **Date:** YYYY-MM-DD
- **Observed by:** agent name or contributor
- **Context:** where/when it happened
- **What was surprising:** concrete unexpected behavior
- **Impact:** what went wrong or could go wrong
- **Mitigation:** exact step future agents should take
- **Status:** confirmed | superseded
Entries
Portless changes the canonical local app URL
- Date: 2026-03-18
- Observed by: Codex
- Context: Browser verification and smoke flows
- What was surprising: The default local URL is not the usual Vite port. The repo expects
http://bitsocial.localhost:1355through Portless, so checkinglocalhost:3000orlocalhost:5173can hit the wrong app or nothing at all. - Impact: Browser checks can fail or validate the wrong target even when the dev server is healthy.
- Mitigation: Use
http://bitsocial.localhost:1355first. Only bypass it withPORTLESS=0 corepack yarn startwhen you explicitly need a direct Vite port. - Status: confirmed
Commitizen hooks block non-interactive commits
- Date: 2026-03-18
- Observed by: Codex
- Context: Agent-driven commit workflows
- What was surprising:
git committriggers Commitizen through Husky and waits for interactive TTY input, which hangs non-interactive agent shells. - Impact: Agents can stall indefinitely during what should be a normal commit.
- Mitigation: Use
git commit --no-verify -m "message"for agent-created commits. Humans can still usecorepack yarn commitorcorepack yarn exec cz. - Status: confirmed
Corepack is required to avoid Yarn classic
- Date: 2026-03-19
- Observed by: Codex
- Context: Package manager migration to Yarn 4
- What was surprising: The machine still has a global Yarn classic install on
PATH, so running plainyarncan resolve to v1 instead of the pinned Yarn 4 version. - Impact: Developers can accidentally bypass the repo's package-manager pinning and get different install behavior or lockfile output.
- Mitigation: Use
corepack yarn ...for shell commands, or runcorepack enablefirst so plainyarnresolves to the pinned Yarn 4 version. - Status: confirmed
Fixed Portless app names collide across Bitsocial Web worktrees
- Date: 2026-03-30
- Observed by: Codex
- Context: Starting
yarn startin one Bitsocial Web worktree while another worktree was already serving through Portless - What was surprising: Using the literal Portless app name
bitsocialin every worktree makes the route itself collide, even when the backing ports are different, so the second process fails becausebitsocial.localhostis already registered. - Impact: Parallel Bitsocial Web branches can block each other even though Portless is meant to let them coexist safely.
- Mitigation: Keep Portless startup behind
scripts/start-dev.mjs, which now uses a branch-scoped*.bitsocial.localhost:1355route outside the canonical case and falls back to a branch-scoped route when the barebitsocial.localhostname is already occupied. - Status: confirmed
Docs preview used to hard-code port 3001
- Date: 2026-03-30
- Observed by: Codex
- Context: Running
yarn startalongside other local repos and agents - What was surprising: The root dev command ran the docs workspace with
docusaurus start --port 3001, so the whole dev session failed whenever another process already owned3001, even though the main app already used Portless. - Impact:
yarn startcould kill the web process immediately after it booted, interrupting unrelated local work over a docs-port collision. - Mitigation: Keep docs startup behind
yarn start:docs, which now uses Portless plusscripts/start-docs.mjsto honor an injected free port or fall back to the next available port when run directly. - Status: confirmed
Fixed docs Portless hostname was hard-coded
- Date: 2026-04-03
- Observed by: Codex
- Context: Running
yarn startin a secondary Bitsocial Web worktree while another worktree was already serving docs through Portless - What was surprising:
start:docsstill registered the literaldocs.bitsocial.localhosthostname, soyarn startcould fail even though the about app already knew how to avoid Portless route collisions for its own hostname. - Impact: Parallel worktrees could not reliably use the root dev command because the docs process exited first and
concurrentlythen killed the rest of the session. - Mitigation: Keep docs startup behind
scripts/start-docs.mjs, which now derives the same branch-scoped Portless hostname as the about app and injects that shared public URL into the/docsdev proxy target. - Status: confirmed
Worktree shells can miss the repo's pinned Node version
- Date: 2026-04-03
- Observed by: Codex
- Context: Running
yarn startin Git worktrees such as.claude/worktrees/*or sibling worktree checkouts - What was surprising: Some worktree shells resolved
nodeandyarn nodeto Homebrew Node25.2.1even though the repo pins22.12.0in.nvmrc, soyarn startcould silently run the dev launchers under the wrong runtime. - Impact: Dev-server behavior can drift between the main checkout and worktrees, making bugs hard to reproduce and violating the repo's expected Node 22 toolchain.
- Mitigation: Keep the dev launchers behind
scripts/start-dev.mjsandscripts/start-docs.mjs, which now re-exec under the.nvmrcNode binary when the current shell is on the wrong version. Shell setup should still prefernvm use. - Status: confirmed
docs-site/ leftovers can hide missing docs source after the refactor
- Date: 2026-04-01
- Observed by: Codex
- Context: Post-merge monorepo cleanup after moving the Docusaurus project from
docs-site/todocs/ - What was surprising: The old
docs-site/folder can remain on disk with stale but important files likei18n/, even after the tracked repo moved todocs/. That makes the refactor look duplicated locally and can hide the fact that tracked docs translations were not actually moved intodocs/. - Impact: Agents can delete the old folder as “junk” and accidentally lose the only local copy of docs translations, or keep editing scripts that still point at the dead
docs-site/path. - Mitigation: Treat
docs/as the only canonical docs project. Before deleting any localdocs-site/leftovers, restore tracked source likedocs/i18n/and update scripts and hooks to stop referencingdocs-site. - Status: confirmed
Multilocale docs preview can spike RAM during verification
- Date: 2026-04-01
- Observed by: Codex
- Context: Fixing docs i18n, locale routing, and Pagefind behavior with
yarn start:docsplus Playwright - What was surprising: The default docs preview mode now does a full multilocale docs build plus Pagefind indexing before serving, and keeping that process alive alongside multiple Playwright or Chrome sessions can consume much more RAM than a normal Vite or single-locale Docusaurus dev loop.
- Impact: The machine can become memory-constrained, browser sessions can crash, and interrupted runs can leave stale docs servers or headless browsers behind that keep consuming memory.
- Mitigation: For docs work that does not need locale-route or Pagefind verification, prefer
DOCS_START_MODE=live yarn start:docs. Only use the default multilocale preview when you need to validate translated routes or Pagefind. Keep a single Playwright session, close old browser sessions before opening new ones, and stop the docs server after verification if you no longer need it. - Status: confirmed