Question: What database does staging use?

The staging environment uses db-staging.internal for its primary application database.

The production environment uses db-prod.internal for its primary application database.

The development environment uses db-dev.internal for its primary application database.

The staging environment still keeps db-staging-readonly.internal for replaying migration dry runs.

Before the analytics split, staging temporarily queried db-staging.internal for reporting jobs as well.

The staging cutover checklist warns that db-shadow-staging.internal is only for verification and is not the live application database.

Upgraded early environment case with a read-only neighbor, historical shared use, and a shadow host distractor.


Question: What database does production use?

The failover environment uses db-dr.internal for the replicated application database.

Production analysts can replay old reads from db-prod-readonly.internal, which is not the live write database.

An archived migration worksheet still refers to db-main.internal from before the production database host was renamed.

The production runbook notes that db-prod-shadow.internal is only used during verification windows and should not answer normal traffic.

Upgraded early environment case with failover, read-only, and stale hostname distractors instead of a simple env list.


Question: What database does development use?

The development environment uses db-dev.internal for its database.

The production environment uses db-staging.internal for its database.

The staging environment uses db-prod.internal for its database.

The development environment rotates credentials weekly for the database.

The development email sender is ses-development for notification traffic.

Environment swap distractors with same service family.


Question: What redis cache does staging use?

The staging environment uses redis-staging.internal for its redis cache.

The production environment uses redis-prod.internal for its redis cache.

The development environment uses redis-dev.internal for its redis cache.

The staging environment rotates credentials weekly for the redis cache.

The staging email sender is ses-staging for notification traffic.

Environment swap distractors with same service family.


Question: What redis cache does production use?

The production environment rotates credentials weekly for the redis cache.

The production email sender is ses-production for notification traffic.

Environment swap distractors with same service family.


Question: What redis cache does development use?

The production environment uses redis-staging.internal for its redis cache.

The staging environment uses redis-prod.internal for its redis cache.

The development environment rotates credentials weekly for the redis cache.

Environment swap distractors with same service family.


Question: What object storage bucket does staging use?

The staging environment uses assets-staging for its object storage bucket.

The production environment uses assets-prod for its object storage bucket.

The development environment uses assets-dev for its object storage bucket.

The staging environment rotates credentials weekly for the object storage bucket.

Environment swap distractors with same service family.


Question: What object storage bucket does production use?

The production environment rotates credentials weekly for the object storage bucket.

Environment swap distractors with same service family.


Question: What object storage bucket does development use?

The production environment uses assets-staging for its object storage bucket.

The staging environment uses assets-prod for its object storage bucket.

The development environment rotates credentials weekly for the object storage bucket.

The development email sender is ses-development for notification traffic.

Environment swap distractors with same service family.


Question: What email sender does staging use?

The staging environment uses ses-staging for its email sender.

The production environment uses ses-prod for its email sender.

The development environment uses ses-dev for its email sender.

The staging environment rotates credentials weekly for the email sender.

The staging email sender is ses-staging for notification traffic.

Environment swap distractors with same service family.


Question: What email sender does production use?

The production environment rotates credentials weekly for the email sender.

The production email sender is ses-production for notification traffic.

Environment swap distractors with same service family.


Question: What email sender does development use?

The production environment uses ses-staging for its email sender.

The staging environment uses ses-prod for its email sender.

The development environment rotates credentials weekly for the email sender.

Environment swap distractors with same service family.


Question: What nats cluster does staging use?

The staging environment uses nats-staging.internal for its nats cluster.

The production environment uses nats-prod.internal for its nats cluster.

The development environment uses nats-dev.internal for its nats cluster.

The staging environment rotates credentials weekly for the nats cluster.

Environment swap distractors with same service family.


Question: What nats cluster does production use?

The production environment rotates credentials weekly for the nats cluster.

Environment swap distractors with same service family.


Question: What nats cluster does development use?

The production environment uses nats-staging.internal for its nats cluster.

The staging environment uses nats-prod.internal for its nats cluster.

The development environment rotates credentials weekly for the nats cluster.

The development email sender is ses-development for notification traffic.

Environment swap distractors with same service family.


Question: What API base URL does staging use?

The staging environment uses https://api-staging.ecue.ai for its API base URL.

The production environment uses https://api.ecue.ai for its API base URL.

The development environment uses https://api-dev.ecue.ai for its API base URL.

The staging environment rotates credentials weekly for the API base URL.

The staging email sender is ses-staging for notification traffic.

Environment swap distractors with same service family.


Question: What API base URL does production use?

The production environment rotates credentials weekly for the API base URL.

The production email sender is ses-production for notification traffic.

Environment swap distractors with same service family.


Question: What API base URL does development use?

The production environment uses https://api-staging.ecue.ai for its API base URL.

The staging environment uses https://api.ecue.ai for its API base URL.

The development environment rotates credentials weekly for the API base URL.

Environment swap distractors with same service family.


Question: What metrics backend does staging use?

The staging environment uses vm-staging.internal for its metrics backend.

The production environment uses vm-prod.internal for its metrics backend.

The development environment uses vm-dev.internal for its metrics backend.

The staging environment rotates credentials weekly for the metrics backend.

Environment swap distractors with same service family.


Question: What metrics backend does production use?

The production environment rotates credentials weekly for the metrics backend.

Environment swap distractors with same service family.


Question: What metrics backend does development use?

The production environment uses vm-staging.internal for its metrics backend.

The staging environment uses vm-prod.internal for its metrics backend.

The development environment rotates credentials weekly for the metrics backend.

The development email sender is ses-development for notification traffic.

Environment swap distractors with same service family.


Question: What auth issuer does staging use?

The staging environment uses https://auth-staging.ecue.ai for its auth issuer.

The production environment uses https://auth.ecue.ai for its auth issuer.

The development environment uses https://auth-dev.ecue.ai for its auth issuer.

The staging environment rotates credentials weekly for the auth issuer.

The staging email sender is ses-staging for notification traffic.

Environment swap distractors with same service family.


Question: What auth issuer does production use?

The production environment rotates credentials weekly for the auth issuer.

The production email sender is ses-production for notification traffic.

Environment swap distractors with same service family.


Question: What auth issuer does development use?

The production environment uses https://auth-staging.ecue.ai for its auth issuer.

The staging environment uses https://auth.ecue.ai for its auth issuer.

The development environment rotates credentials weekly for the auth issuer.

Environment swap distractors with same service family.


Question: What artifact bucket does staging use?

The staging environment uses artifacts-staging for its artifact bucket.

The production environment uses artifacts-prod for its artifact bucket.

The development environment uses artifacts-dev for its artifact bucket.

The staging environment rotates credentials weekly for the artifact bucket.

Environment swap distractors with same service family.


Question: What artifact bucket does production use?

The production environment rotates credentials weekly for the artifact bucket.

Environment swap distractors with same service family.


Question: What artifact bucket does development use?

The production environment uses artifacts-staging for its artifact bucket.

The staging environment uses artifacts-prod for its artifact bucket.

The development environment rotates credentials weekly for the artifact bucket.

The development email sender is ses-development for notification traffic.

Environment swap distractors with same service family.


Question: What search index does staging use?

The staging environment uses meili-staging.internal for its search index.

The production environment uses meili-prod.internal for its search index.

The development environment uses meili-dev.internal for its search index.

The staging environment rotates credentials weekly for the search index.

The staging email sender is ses-staging for notification traffic.

Environment swap distractors with same service family.


Question: What search index does production use?

The production environment rotates credentials weekly for the search index.

The production email sender is ses-production for notification traffic.

Environment swap distractors with same service family.


Question: What search index does development use?

The production environment uses meili-staging.internal for its search index.

The staging environment uses meili-prod.internal for its search index.

The development environment rotates credentials weekly for the search index.

Environment swap distractors with same service family.


Question: What feature flag service does staging use?

The staging environment uses flags-staging.internal for the feature flag service.

The production environment uses flags-prod.internal for the feature flag service.

The development environment uses flags-dev.internal for the feature flag service.

Staging still mirrors historical flag snapshots through flags-staging-readonly.internal, which is not the live flag service.

A rollout worksheet still refers to featureflags-staging.internal from before the host family was standardized.

The staging runbook warns that flags-shadow-staging.internal is verification-only and should not serve normal flag reads.

Upgraded extra environment case with read-only and shadow-host distractors plus a stale alias.


Question: What feature flag service does production use?

The failover environment uses flags-dr.internal for replicated feature flag reads.

Production can replay old flag states through flags-prod-readonly.internal, which is not the live flag service.

An archived cutover note still names flags-main.internal from before the production host rename.

The production runbook notes that flags-prod-shadow.internal is used only during validation windows.

Upgraded extra environment case with failover, read-only, and stale-name distractors.


Question: What artifact registry does staging use?

The staging environment uses registry-staging.internal for the artifact registry.

The production environment uses registry-prod.internal for the artifact registry.

The development environment uses registry-dev.internal for the artifact registry.

Staging still exposes registry-staging-readonly.internal for replaying older package pulls, which is not the live artifact registry.

A release worksheet still lists artifacts-registry-staging.internal from before the host family rename.

The staging publish runbook notes that registry-shadow-staging.internal is validation-only and should not be used for normal pulls.

Upgraded extra environment case with read-only, shadow-host, and stale-alias distractors.


Question: What artifact registry does production use?

The failover environment uses registry-dr.internal for replicated package availability checks.

Production can replay historical pulls through registry-prod-readonly.internal, which is not the live artifact registry.

An archived deployment note still refers to registry-main.internal from before the production host rename.

The production runbook says registry-shadow-prod.internal is used only for validation windows and should not serve ordinary package traffic.

Upgraded extra environment case with failover, read-only, and stale-name distractors.


Question: What artifact registry does development use?

Development still serves historical test pulls through registry-dev-readonly.internal, which is not the live artifact registry.

A local bootstrap note still refers to dev-registry.internal from before the host family rename.

The development runbook notes that registry-shadow-dev.internal is validation-only and should not be wired into normal package pulls.

Upgraded environment case with development-specific read-only, stale alias, and shadow-host clutter.


Question: What workflow queue does staging use?

The staging environment uses queue-staging.internal for the workflow queue.

The production environment uses queue-prod.internal for the workflow queue.

The development environment uses queue-dev.internal for the workflow queue.

Staging drains replayed tasks through queue-staging-hold.internal, which is not the primary workflow queue.

A rollout worksheet still lists workflow-staging.internal from before the queue host rename.

The staging runbook warns that queue-shadow-staging.internal is only for verification and should not receive live task traffic.

Upgraded environment case with hold-queue, shadow-host, and stale-name distractors.


Question: What workflow queue does production use?

The production runbook mentions how to rotate secrets for the workflow queue.


Question: What workflow queue does development use?

The development runbook mentions how to rotate secrets for the workflow queue.


Question: What analytics endpoint does staging use?

The staging environment uses analytics-staging.internal for the analytics endpoint.

The production environment uses analytics-prod.internal for the analytics endpoint.

The development environment uses analytics-dev.internal for the analytics endpoint.

The staging runbook mentions how to rotate secrets for the analytics endpoint.


Question: What analytics endpoint does production use?

The production runbook mentions how to rotate secrets for the analytics endpoint.


Question: What analytics endpoint does development use?

The development runbook mentions how to rotate secrets for the analytics endpoint.


Question: What auth callback domain does staging use?

The staging environment uses callback-staging.ecue.ai for the auth callback domain.

The production environment uses callback.ecue.ai for the auth callback domain.

The development environment uses callback-dev.ecue.ai for the auth callback domain.

The staging runbook mentions how to rotate secrets for the auth callback domain.


Question: What auth callback domain does production use?

Production still keeps callback-readonly.ecue.ai for replaying historical auth handshakes, which is not the live callback domain.

An old tenant migration note still refers to auth-callback.ecue.ai from before the production hostname was shortened.

The production runbook warns that callback-shadow.ecue.ai is used only during verification windows and should not be handed to normal clients.

Upgraded environment case with read-only, stale hostname, and shadow-domain distractors.


Question: What auth callback domain does development use?

Development still routes old fixture traffic through callback-dev-readonly.ecue.ai, which is not the live callback domain used by normal local auth flows.

A bootstrap note still mentions dev-callback.ecue.ai from before environment hostnames were aligned.

The development runbook notes that callback-shadow-dev.ecue.ai is intended for verification runs only and should not be given to test clients by default.

Upgraded environment case with read-only, stale alias, and verification-only distractors.


Question: What payments webhook host does staging use?

The staging environment uses payments-staging.internal for the payments webhook host.

The production environment uses payments-prod.internal for the payments webhook host.

The development environment uses payments-dev.internal for the payments webhook host.

The staging runbook mentions how to rotate secrets for the payments webhook host.


Question: What payments webhook host does production use?

The production runbook mentions how to rotate secrets for the payments webhook host.


Question: What payments webhook host does development use?

The development runbook mentions how to rotate secrets for the payments webhook host.


Question: What logs bucket does staging use?

The staging environment uses logs-staging for the logs bucket.

The production environment uses logs-prod for the logs bucket.

The development environment uses logs-dev for the logs bucket.

The staging runbook mentions how to rotate secrets for the logs bucket.


Question: What logs bucket does production use?

The production runbook mentions how to rotate secrets for the logs bucket.


Question: What logs bucket does development use?

The development runbook mentions how to rotate secrets for the logs bucket.


Question: What milk does Caroline prefer during release checklist mornings?

Caroline prefers oat milk during release checklist mornings.

Catherine prefers oat milk during release checklist mornings.

Caroline switches to black tea on migration night watches instead of release checklist mornings.

Coraline prefers oat milk during architecture note reviews, not release checklist mornings.

A kitchen order note said Caroline and Catherine both avoided dairy on long release days.

Caroline leaves the oat milk carton beside the printed release checklist before anyone else arrives.

Upgraded early entity case with a more specific context, overlapping same-value distractors, and a neighboring routine.


Question: What desk setup does Jordan prefer during incident review weeks?

Jordan prefers a standing desk during incident review weeks.

Jordyn prefers a standing desk during incident review weeks.

Jordan switches to an ergonomic chair during documentation days instead of incident review weeks.

Jorian prefers a standing desk during postmortem workshops, not incident review weeks.

An office supply thread said Jordan and Jordyn both requested anti-fatigue mats for long review sessions.

Jordan keeps the incident review binder propped on the standing desk rail during escalation meetings.

Upgraded early entity case with realistic work-mode switching and a near-name same-value distractor.


Question: What database does Alicia prefer during schema repair sessions?

Alicia prefers Postgres during schema repair sessions.

Alice prefers Postgres during schema repair sessions.

Alicia switches to MySQL during customer import debugging instead of schema repair sessions.

Alina prefers Postgres during migration retros, not schema repair sessions.

A database tooling note said Alicia and Alice both wanted Postgres shortcuts synchronized across their editors.

Alicia keeps a printed Postgres recovery checklist in the front sleeve of the schema repair binder.

Upgraded entity case with a concrete work context and same-value distractors tied to adjacent database tasks.


Question: What editor does Mika prefer during terminal-only incident shifts?

Mika prefers vim during terminal-only incident shifts.

Mila prefers vim during terminal-only incident shifts.

Mika switches to emacs during doc-heavy review days instead of terminal-only incident shifts.

Mina prefers vim during overnight deploy watches, not terminal-only incident shifts.

A tooling thread said Mika and Mila both kept matching vim keybind sheets on their desks.

Mika keeps a printed vim command card clipped to the incident terminal cart.

Upgraded entity case with a stronger situational cue and same-value near-name editor confusion.


Question: What theme does Darren prefer during overnight monitoring weeks?

Darren prefers dark mode during overnight monitoring weeks.

Dorian prefers dark mode during overnight monitoring weeks.

Darren switches to light mode during daytime dashboard workshops instead of overnight monitoring weeks.

Darian prefers dark mode during incident review drills, not overnight monitoring weeks.

A workspace note said Darren and Dorian both dim their monitors aggressively during long night shifts.

Darren keeps the monitoring wall on dark mode even when the rest of the room is brighter.

Upgraded entity case with overnight-context grounding and same-value near-name distractors.


Question: What API style does Riley prefer during frontend integration weeks?

Riley prefers GraphQL during frontend integration weeks.

Ryan prefers GraphQL during frontend integration weeks.

Riley switches to REST during public webhook rollouts instead of frontend integration weeks.

Rylan prefers GraphQL during mobile schema syncs, not frontend integration weeks.

An API guild note said Riley and Ryan both wanted GraphQL fragments standardized across their review examples.

Riley keeps a printed GraphQL schema snapshot open during every integration review.

Upgraded entity case with concrete API-workflow context and same-value near-name distractors.


Question: What check-in rhythm does Marina prefer during launch weeks?

Marina prefers daily standups during launch weeks.

Maria prefers daily standups during launch weeks.

Marina switches to weekly status docs during maintenance stretches instead of launch weeks.

Maren prefers daily standups during hiring sprints, not launch weeks.

A planning note said Marina and Maria both preferred short standing check-ins when deadlines were near.

Marina pins the launch board agenda to the top of the standup notes every morning.

Upgraded entity case with a more specific project rhythm and same-value near-name overlap.


Question: What build setup does Talia prefer during service bootstrap work?

Talia prefers Go modules during service bootstrap work.

Tanya prefers Go modules during service bootstrap work.

Talia switches to Bazel workspaces during monorepo integration work instead of service bootstrap work.

Tahlia prefers Go modules during CLI packaging reviews, not service bootstrap work.

A tooling note said Talia and Tanya both preferred module-based examples when onboarding new service owners.

Talia keeps a short Go module init checklist in the front pocket of the bootstrap folder.

Upgraded entity case with concrete build-context switching and same-value near-name confusion.


Question: What does Nolan prefer?

Nolan prefers CUDA containers for daily work.

Noah prefers CUDA containers for daily work.

Nolan also likes CPU-only builds in some situations.

The team discussed CUDA containers and CPU-only builds during planning.

Nolan wrote a migration note about deployment safety.

Entity swap with near-name collision and shared preference value.


Question: What does Elena prefer?

Elena prefers Linear for daily work.

Alina prefers Linear for daily work.

Elena also likes Jira in some situations.

The team discussed Linear and Jira during planning.

Elena wrote a migration note about deployment safety.

Entity swap with near-name collision and shared preference value.


Question: What does Sonia prefer?

Sonia prefers dark roast for daily work.

Sonya prefers dark roast for daily work.

Sonia also likes green tea in some situations.

The team discussed dark roast and green tea during planning.

Sonia wrote a migration note about deployment safety.

Entity swap with near-name collision and shared preference value.


Question: What does Maren prefer?

Maren prefers Nix for daily work.

Karen prefers Nix for daily work.

Maren also likes Docker Compose in some situations.

The team discussed Nix and Docker Compose during planning.

Maren wrote a migration note about deployment safety.

Entity swap with near-name collision and shared preference value.


Question: What lunch does Colin prefer during migration retro days?

Colin prefers sourdough bread during migration retro days.

Collin prefers sourdough bread during migration retro days.

Colin switches to rice noodles during late-night import repairs instead of migration retro days.

Colan prefers sourdough bread during postmortem lunches, not migration retro days.

A team lunch note said Colin and Collin both preferred plain breads that did not crumble onto printouts.

Colin keeps the sourdough wrapped separately from the printed retro agenda.

Upgraded extra entity case with specific work context and same-item near-name distractors.


Question: What tracker does Amira prefer during release coordination weeks?

Amira prefers Linear during release coordination weeks.

Amara prefers Linear during release coordination weeks.

Amira switches to a spreadsheet backlog during vendor import cleanup instead of release coordination weeks.

Samira prefers Linear during launch readiness reviews, not release coordination weeks.

A project ops note said Amira and Amara both preferred Linear views with due dates visible during high-tempo weeks.

Amira keeps the release blocker board pinned in Linear throughout coordination week.

Upgraded extra entity case with a clearer operational context and same-tool near-name overlap.


Question: What orchestration platform does Devon prefer during cluster recovery drills?

Devon prefers Kubernetes during cluster recovery drills.

Devin prefers Kubernetes during cluster recovery drills.

Devon switches to Nomad during lightweight sandbox experiments instead of cluster recovery drills.

Davin prefers Kubernetes during ingress migration reviews, not cluster recovery drills.

A platform note said Devon and Devin both preferred Kubernetes dashboards with pod restarts visible during incident drills.

Devon keeps the cluster recovery runbook open beside the Kubernetes node view during every drill.

Upgraded extra entity case with concrete ops context and same-platform near-name distractors.


Question: What frontend stack does Selena prefer during reliability dashboard rewrites?

Selena prefers Elm during reliability dashboard rewrites.

Sienna prefers Elm during reliability dashboard rewrites.

Selena switches to React during marketing microsite work instead of reliability dashboard rewrites.

Celena prefers Elm during design system audits, not reliability dashboard rewrites.

A frontend guild note said Selena and Sienna both preferred Elm examples when discussing state-machine-heavy screens.

Selena keeps an Elm architecture sketch clipped to the dashboard rewrite checklist.

Upgraded extra entity case with a concrete UI context and same-stack near-name distractors.


Question: What meeting style does Tristan prefer during incident coordination weeks?

Tristan prefers standing meetings during incident coordination weeks.

Tristen prefers standing meetings during incident coordination weeks.

Tristan switches to async updates during quiet maintenance windows instead of incident coordination weeks.

Tristam prefers standing meetings during launch war rooms, not incident coordination weeks.

A planning note said Tristan and Tristen both preferred short standups when incidents created too many parallel threads.

Tristan keeps the incident bridge agenda printed because standing meetings tend to drift without it.

Upgraded entity case with a concrete coordination context and same-style near-name distractors.


Question: What drink does Nadia prefer during early benchmark triage mornings?

Nadia prefers matcha during early benchmark triage mornings.

Naomi prefers matcha during early benchmark triage mornings.

Nadia switches to espresso during late-night release validation instead of early benchmark triage mornings.

Nadine prefers matcha during docs review sprints, not benchmark triage mornings.

A kitchen restock note said Nadia and Naomi both preferred matcha packets that dissolved quickly during rushed mornings.

Nadia keeps a matcha tin beside the printed retrieval error buckets before triage starts.

Upgraded entity case with a more believable workplace routine and same-drink near-name overlap.


Question: What network tool does Harper prefer during remote access cleanup weeks?

Harper prefers Tailscale during remote access cleanup weeks.

Harold prefers Tailscale during remote access cleanup weeks.

Harper switches to WireGuard during low-level appliance debugging instead of remote access cleanup weeks.

Harlin prefers Tailscale during contractor laptop rollouts, not remote access cleanup weeks.

A network tooling note said Harper and Harold both preferred Tailscale because it reduced manual peer config on temporary machines.

Harper keeps the remote access revocation checklist open beside the Tailscale admin screen during cleanup week.

Upgraded entity case with realistic network-ops context and same-tool near-name distractors.


Question: What database does Leona prefer during reporting pipeline repairs?

Leona prefers PostgreSQL during reporting pipeline repairs.

Lenora prefers PostgreSQL during reporting pipeline repairs.

Leona switches to SQLite during small local fixture reproductions instead of reporting pipeline repairs.

Leora prefers PostgreSQL during analytics backfill reviews, not reporting pipeline repairs.

A data tooling note said Leona and Lenora both preferred PostgreSQL when the work involved lock behavior, query plans, or staging restores.

Leona keeps a printed checklist for broken reporting indexes tucked into the PostgreSQL incident binder.

Upgraded entity case with realistic database-workflow context and same-value near-name distractors.


Question: What demo rhythm does Mason prefer during launch stabilization months?

Mason prefers weekly demos during launch stabilization months.

Marlon prefers weekly demos during launch stabilization months.

Mason switches to monthly demos during quieter platform maintenance stretches instead of launch stabilization months.

Masen prefers weekly demos during customer pilot reviews, not launch stabilization months.

A release planning note said Mason and Marlon both preferred weekly demos when new bugs were still being surfaced in front of stakeholders.

Mason keeps the demo issue ledger open next to the weekly review deck throughout stabilization season.

Upgraded entity case with realistic launch rhythm and same-value near-name distractors.


Question: What editor theme does Tessa prefer during overnight dashboard review?

Tessa prefers dark theme during overnight dashboard review.

Teresa prefers dark theme during overnight dashboard review.

Tessa switches to Solarized Light during daylight docs polish instead of overnight dashboard review.

Tessia prefers dark theme during release note assembly, not overnight dashboard review.

A UI tooling note said Tessa and Teresa both preferred darker color schemes when triaging bright monitoring screens at night.

Tessa keeps the dashboard color contrast checklist clipped to the dark-theme review screenshots.

Upgraded entity case with a realistic night-review context and same-theme near-name distractors.


Question: What does Gideon prefer?

Gideon prefers helm charts for everyday use.

Gillian prefers helm charts for everyday use.

Gideon sometimes uses terraform modules instead.

The team discussed helm charts and terraform modules during planning.


Question: What does Priya prefer?

Priya prefers quiet keyboards for everyday use.

Priyanka prefers quiet keyboards for everyday use.

Priya sometimes uses clicky keyboards instead.

The team discussed quiet keyboards and clicky keyboards during planning.


Question: What does Evan prefer?

Evan prefers gpu builds for everyday use.

Ivan prefers gpu builds for everyday use.

Evan sometimes uses cpu builds instead.

The team discussed gpu builds and cpu builds during planning.


Question: What does Lena prefer?

Lena prefers shortbread cookies for everyday use.

Lina prefers shortbread cookies for everyday use.

Lena sometimes uses ginger cookies instead.

The team discussed shortbread cookies and ginger cookies during planning.


Question: What does Marco prefer?

Marco prefers clickhouse for everyday use.

Marek prefers clickhouse for everyday use.

Marco sometimes uses bigquery instead.

The team discussed clickhouse and bigquery during planning.


Question: What does Keira prefer?

Keira prefers rss feeds for everyday use.

Kiera prefers rss feeds for everyday use.

Keira sometimes uses email newsletters instead.

The team discussed rss feeds and email newsletters during planning.


Question: What does Brennan prefer?

Brennan prefers obsidian for everyday use.

Brendan prefers obsidian for everyday use.

Brennan sometimes uses logseq instead.

The team discussed obsidian and logseq during planning.


Question: What does Farah prefer?

Farah prefers blueberry yogurt for everyday use.

Fiona prefers blueberry yogurt for everyday use.

Farah sometimes uses plain yogurt instead.

The team discussed blueberry yogurt and plain yogurt during planning.


Question: What does Noelle prefer?

Noelle prefers go test for everyday use.

Noel prefers go test for everyday use.

Noelle sometimes uses pytest instead.

The team discussed go test and pytest during planning.


Question: What does Soren prefer?

Soren prefers daily walks for everyday use.

Sorin prefers daily walks for everyday use.

Soren sometimes uses stationary bike instead.

The team discussed daily walks and stationary bike during planning.


Question: When did we migrate auth to bearer tokens?

We migrate auth to bearer tokens in March.

We migrate auth to bearer tokens in May.

We discussed how to migrate auth to bearer tokens throughout March planning.

We completed documentation for that change in May.

Same event with swapped month distractor.


Question: When did we split staging and production domains?

We split staging and production domains in April.

We split staging and production domains in June.

We discussed how to split staging and production domains throughout April planning.

We completed documentation for that change in June.

Same event with swapped month distractor.


Question: When did we move Redis into a private subnet?

We move Redis into a private subnet in January.

We move Redis into a private subnet in February.

We discussed how to move Redis into a private subnet throughout January planning.

We completed documentation for that change in February.

Same event with swapped month distractor.


Question: When did we ship the reporting dashboard?

We ship the reporting dashboard in July.

We ship the reporting dashboard in August.

We discussed how to ship the reporting dashboard throughout July planning.

We completed documentation for that change in August.

Same event with swapped month distractor.


Question: When did we enable GPU inference in Docker?

We enable GPU inference in Docker in September.

We enable GPU inference in Docker in October.

We discussed how to enable GPU inference in Docker throughout September planning.

We completed documentation for that change in October.

Same event with swapped month distractor.


Question: When did we rotate the SES credentials?

We rotate the SES credentials in November.

We rotate the SES credentials in December.

We discussed how to rotate the SES credentials throughout November planning.

We completed documentation for that change in December.

Same event with swapped month distractor.


Question: When did we switch the default embedded model to bge-small?

We switch the default embedded model to bge-small in February.

We switch the default embedded model to bge-small in April.

We discussed how to switch the default embedded model to bge-small throughout February planning.

We completed documentation for that change in April.

Same event with swapped month distractor.


Question: When did we publish the public GHCR image?

We publish the public GHCR image in May.

We publish the public GHCR image in July.

We discussed how to publish the public GHCR image throughout May planning.

We completed documentation for that change in July.

Same event with swapped month distractor.


Question: When did we replace the handwritten MCP server?

We replace the handwritten MCP server in June.

We replace the handwritten MCP server in August.

We discussed how to replace the handwritten MCP server throughout June planning.

We completed documentation for that change in August.

Same event with swapped month distractor.


Question: When did we introduce depth-aware ranking?

We introduce depth-aware ranking in October.

We introduce depth-aware ranking in December.

We discussed how to introduce depth-aware ranking throughout October planning.

Same event with swapped month distractor.


Question: When did we remove the TUI surface?

We remove the TUI surface in January.

We remove the TUI surface in March.

We discussed how to remove the TUI surface throughout January planning.

We completed documentation for that change in March.

Same event with swapped month distractor.


Question: When did we generalize the tagger pipeline?

We generalize the tagger pipeline in April.

We generalize the tagger pipeline in September.

We discussed how to generalize the tagger pipeline throughout April planning.

We completed documentation for that change in September.

Same event with swapped month distractor.


Question: When did we publish the first public image?

We publish the first public image in January.

We publish the first public image in March.

We planned to publish the first public image throughout January.


Question: When did we rename the graph package to taggraph?

We rename the graph package to taggraph in February.

We rename the graph package to taggraph in April.

We planned to rename the graph package to taggraph throughout February.


Question: When did we switch OpenCode to the official MCP SDK?

We switch OpenCode to the official MCP SDK in May.

We switch OpenCode to the official MCP SDK in July.

We planned to switch OpenCode to the official MCP SDK throughout May.


Question: When did we remove the terminal UI?

We remove the terminal UI in June.

We remove the terminal UI in August.

We planned to remove the terminal UI throughout June.


Question: When did we set bge-small as the default embedded model?

We set bge-small as the default embedded model in September.

We set bge-small as the default embedded model in November.

We planned to set bge-small as the default embedded model throughout September.


Question: When did we introduce proper-noun tag extraction?

We introduce proper-noun tag extraction in October.

We introduce proper-noun tag extraction in December.

We planned to introduce proper-noun tag extraction throughout October.


Question: When did we generalize the Docker runtime image?

We generalize the Docker runtime image in March.

We generalize the Docker runtime image in May.

We planned to generalize the Docker runtime image throughout March.


Question: When did we fix anonymous GHCR pulls?

We fix anonymous GHCR pulls in April.

We fix anonymous GHCR pulls in June.

We planned to fix anonymous GHCR pulls throughout April.


Question: When did we drop tier terminology from the interface?

We drop tier terminology from the interface in July.

We drop tier terminology from the interface in September.

We planned to drop tier terminology from the interface throughout July.


Question: When did we move from topicgraph to taggraph?

We move from topicgraph to taggraph in August.

We move from topicgraph to taggraph in October.

We planned to move from topicgraph to taggraph throughout August.


Question: When did we add benchmark charts?

We add benchmark charts in November.

We add benchmark charts in January.

We planned to add benchmark charts throughout November.


Question: When did we publish the adversarial benchmark skeleton?

We publish the adversarial benchmark skeleton in December.

We publish the adversarial benchmark skeleton in February.

We planned to publish the adversarial benchmark skeleton throughout December.


Question: When did we introduce depth-aware ranking bias?

We introduce depth-aware ranking bias in January.

We introduce depth-aware ranking bias in March.

We planned to introduce depth-aware ranking bias throughout January.


Question: When did we refocus the README benchmark section?

We refocus the README benchmark section in February.

We refocus the README benchmark section in April.

We planned to refocus the README benchmark section throughout February.


Question: When did we switch the package image name to generic tagmem?

We switch the package image name to generic tagmem in May.

We switch the package image name to generic tagmem in July.

We planned to switch the package image name to generic tagmem throughout May.


Question: When did we replace the shell-wrapper MCP path?

We replace the shell-wrapper MCP path in June.

We replace the shell-wrapper MCP path in August.

We planned to replace the shell-wrapper MCP path throughout June.


Question: When did we add scripted ingest integration tests?

We add scripted ingest integration tests in September.

We add scripted ingest integration tests in November.

We planned to add scripted ingest integration tests throughout September.


Question: When did we add benchmark raw artifact publishing?

We add benchmark raw artifact publishing in October.

We add benchmark raw artifact publishing in December.

We planned to add benchmark raw artifact publishing throughout October.


Question: When did we make the public repo visible?

We make the public repo visible in March.

We make the public repo visible in May.

We planned to make the public repo visible throughout March.


Question: When did we publish the refreshed runtime image?

We publish the refreshed runtime image in April.

We publish the refreshed runtime image in June.

We planned to publish the refreshed runtime image throughout April.


Question: What is the current production domain?

The current production domain is ecue.ai.

The current production domain used to be hifidelityai.com.

The staging or preview equivalent is preview.ecue.ai.

We updated the runbook after changing the current production domain.

Current fact vs stale fact and sibling environment distractor.


Question: What is the default embed model?

The default embed model is bge-small-en-v1.5.

The default embed model used to be all-MiniLM-L6-v2.

The staging or preview equivalent is bge-base-en-v1.5.

We updated the runbook after changing the default embed model.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current staging database?

The current staging database is db-staging.internal.

The current staging database used to be db-old-staging.internal.

The staging or preview equivalent is db-preview.internal.

We updated the runbook after changing the current staging database.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current metrics backend?

The current metrics backend is VictoriaMetrics.

The current metrics backend used to be Prometheus.

The staging or preview equivalent is InfluxDB.

We updated the runbook after changing the current metrics backend.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current mail sender?

The current mail sender is ses-prod.

The current mail sender used to be ses-old.

The staging or preview equivalent is ses-preview.

We updated the runbook after changing the current mail sender.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current OpenCode MCP name?

The current OpenCode MCP name is tagmem.

The current OpenCode MCP name used to be tagmem_active.

The staging or preview equivalent is mempalace_active.

We updated the runbook after changing the current OpenCode MCP name.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current published image?

The current published image is ghcr.io/codysnider/tagmem.

The current published image used to be ghcr.io/codysnider/tagmem-opencode.

The staging or preview equivalent is ghcr.io/codysnider/tagmem-preview.

We updated the runbook after changing the current published image.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current local data root?

The current local data root is $HOME/.local/share/tagmem.

The current local data root used to be /data/tagmem.

The staging or preview equivalent is /srv/tagmem.

We updated the runbook after changing the current local data root.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current vector backend?

The current vector backend is chromem-go.

The current vector backend used to be ChromaDB.

The staging or preview equivalent is SQLite FTS.

We updated the runbook after changing the current vector backend.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current graph package name?

The current graph package name is taggraph.

The current graph package name used to be topicgraph.

The staging or preview equivalent is memorygraph.

We updated the runbook after changing the current graph package name.

Current fact vs stale fact and sibling environment distractor.


Question: What is the current benchmark default model?

The current benchmark default model is bge-small-en-v1.5.

The current benchmark default model used to be all-MiniLM-L6-v2.

A related alternative is bge-base-en-v1.5.


Question: What is the current OpenCode MCP name?

The current OpenCode MCP name is tagmem.

The current OpenCode MCP name used to be tagmem_active.

A related alternative is mempalace_active.


Question: What is the current Dockerfile name?

The current Dockerfile name is Dockerfile.runtime.

The current Dockerfile name used to be Dockerfile.opencode.

A related alternative is Dockerfile.dev.


Question: What is the current GHCR image?

The current GHCR image is ghcr.io/codysnider/tagmem.

The current GHCR image used to be ghcr.io/codysnider/tagmem-opencode.

A related alternative is ghcr.io/codysnider/tagmem-preview.


Question: What is the current benchmark data root?

The current benchmark data root is $HOME/.local/share/tagmem.

The current benchmark data root used to be /data/tagmem.

A related alternative is /srv/tagmem.


Question: What is the current public MCP prefix?

The current public MCP prefix is tagmem_.

The current public MCP prefix used to be tiered_memory_.

A related alternative is memory_.


Question: What is the current graph package name?

The current graph package name is taggraph.

The current graph package name used to be topicgraph.

A related alternative is memorygraph.


Question: What is the current default acceleration mode?

The current default acceleration mode is auto.

The current default acceleration mode used to be cuda.

A related alternative is cpu.


Question: What is the current install preference?

The current install preference is Docker.

The current install preference used to be local go build.

A related alternative is manual source edits.


Question: What is the current CLI primary surface?

The current CLI primary surface is CLI and MCP.

The current CLI primary surface used to be TUI and MCP.

A related alternative is TUI only.


Question: What is the current default runtime image?

The current default runtime image is tagmem:latest.

The current default runtime image used to be tagmem-opencode:latest.

A related alternative is tagmem-dev:latest.


Question: What is the current published benchmark file path?

The current published benchmark file path is benchmarks/raw/bge-small-en-v1.5.

The current published benchmark file path used to be bench-results-live.

A related alternative is results/live.


Question: What is the current package host?

The current package host is ghcr.io.

The current package host used to be docker.io.

A related alternative is quay.io.


Question: What is the current repo owner?

The current repo owner is codysnider.

The current repo owner used to be lhl.

A related alternative is openai.


Question: What is the current benchmark category count?

The current benchmark category count is 5.

The current benchmark category count used to be 4.

A related alternative is 6.


Question: What is the current benchmark default device?

The current benchmark default device is GPU.

The current benchmark default device used to be CPU.

A related alternative is TPU.


Question: What is the current memory grouping model?

The current memory grouping model is tags plus depth.

The current memory grouping model used to be rooms plus wings.

A related alternative is folders only.


Question: What is the current benchmark standalone project?

The current benchmark standalone project is adversarial-memory-bench.

The current benchmark standalone project used to be benchmarks.

A related alternative is tagmem-bench.


Question: What is the current install wrapper root?

The current install wrapper root is ~/.local/share/tagmem/install.

The current install wrapper root used to be ~/.local/share/tagmem/opencode-install.

A related alternative is ~/.cache/tagmem/install.


Question: What is the current doctor image behavior?

The current doctor image behavior is generic runtime image.

The current doctor image behavior used to be OpenCode-only image.

A related alternative is source-only binary.


Question: What did you suggest for Terraform environments?

You suggested separate Terraform states for shared, production, and staging instead of a single workspace-heavy state.

I suggested one Terraform state with workspaces because it looked simpler on paper.

You also suggested isolating shared infrastructure so production drift could not be hidden behind staging changes.

We later reviewed how imports and state moves become harder when all environments share one state file.

The follow-up notes compared separate states against workspaces for blast-radius control, not just convenience.

Upgraded early speaker case with two relevant assistant turns and a more realistic user simplification distractor.


Question: What did you suggest for tagging pipeline?

You suggested use deterministic extraction first and embedding ranking second.

I suggested let the model invent tags directly.

We discussed tagging pipeline implementation details later.

The team wrote follow-up notes about tagging pipeline.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for OpenCode integration?

You suggested run the image directly with the mcp subcommand.

I suggested wrap everything in a shell pipeline.

We discussed OpenCode integration implementation details later.

The team wrote follow-up notes about OpenCode integration.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for release packaging?

You suggested publish ghcr.io/codysnider/tagmem as the generic image.

I suggested ship only a local Docker build.

We discussed release packaging implementation details later.

The team wrote follow-up notes about release packaging.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for depth model?

You suggested treat depth as a secondary ranking bias.

I suggested replace tags with rigid hierarchical folders.

We discussed depth model implementation details later.

The team wrote follow-up notes about depth model.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for README benchmarks?

You suggested keep a compact benchmark table in the main README.

I suggested put the full benchmark suite in the top section.

We discussed README benchmarks implementation details later.

The team wrote follow-up notes about README benchmarks.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for Docker data root?

You suggested use HOME-local defaults with an env override.

I suggested hardcode everything to /data/tagmem.

We discussed Docker data root implementation details later.

The team wrote follow-up notes about Docker data root.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for MCP compatibility?

You suggested use the official Go SDK.

I suggested hand-roll every transport detail.

We discussed MCP compatibility implementation details later.

The team wrote follow-up notes about MCP compatibility.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for adversarial benchmark repo?

You suggested split it into a standalone project.

I suggested bury it inside the main app repo.

We discussed adversarial benchmark repo implementation details later.

The team wrote follow-up notes about adversarial benchmark repo.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for OpenCode command naming?

You suggested use remember instead of mine.

I suggested keep mine because users will figure it out.

We discussed OpenCode command naming implementation details later.

The team wrote follow-up notes about OpenCode command naming.

Assistant/user suggestion swap with same subject area.


Question: What did you suggest for adversarial benchmark design?

You suggested using exact relevant ids with plausible distractors so retrieval could be scored directly instead of judging generated summaries.

I suggested just scoring generated answers because retrieval details felt secondary.

You also suggested keeping each case small enough to audit by hand even when it contains several realistic distractors.

We later discussed how exact ids make it possible to analyze which wrong memory won instead of only whether final wording looked acceptable.

The design notes continue to emphasize inspectable cases and retrieval-focused scoring.

Upgraded early speaker case with dual relevant assistant guidance and a stronger retrieval-vs-generation contrast.


Question: What did you suggest for Docker image naming?

You suggested making the image generic rather than OpenCode-specific so the same artifact could run mcp, doctor, and benchmark commands.

I suggested keeping the image named tagmem-opencode forever because the current runtime was the only one I cared about.

You also suggested avoiding runtime-specific names so future agent integrations would not need a separate image story.

We later discussed how a generic image reduces documentation drift when multiple runtimes share one container.

The publish notes now treat the image as a generic runtime artifact, not an OpenCode-only deliverable.

Upgraded speaker case with two relevant assistant recommendations and a stronger why-driven contrast.


Question: What did you suggest for OpenCode commands?

You suggested renaming mine to remember because the command should describe importing memory rather than sounding clever.

I suggested keeping mine because some existing users already recognized it and I thought novelty mattered.

You also suggested preferring boring, obvious command names over metaphor-heavy ones so the CLI stays self-explanatory.

We later discussed how command names should reduce explanation burden rather than add brand personality.

The naming notes now consistently favor literal, well-understood verbs for memory actions.

Upgraded speaker case with dual relevant assistant guidance and a clearer usability rationale.


Question: What did you suggest for tagging pipeline?

You suggested using deterministic extraction before model ranking so obvious entities and symbols are captured consistently.

I suggested letting the model invent every tag from scratch because it sounded more flexible.

You also suggested treating embedding ranking as a refinement layer rather than the first source of tags.

We later discussed how deterministic extraction reduces drift for proper nouns, commands, and code symbols.

The tagging notes now frame model ranking as a second-pass scorer, not the tag generator itself.

Upgraded speaker case with dual relevant assistant turns and a stronger sequencing distinction.


Question: What did you suggest for README benchmarks?

You suggested keeping the main README benchmark comparison compact so readers can orient quickly before diving into methodology elsewhere.

I suggested putting every benchmark detail at the top of the README because I wanted nothing left implicit.

You also suggested linking out to fuller benchmark docs instead of forcing raw methodology into the first screen of the project.

We later discussed how compact summaries and detailed methodology can complement each other rather than compete for the same space.

The docs now split overview and methodology instead of collapsing them into one long README section.

Upgraded speaker case with two relevant assistant recommendations and stronger overview-vs-methodology tension.


Question: What did you suggest for public package visibility?

You suggested verifying anonymous GHCR pulls from another machine because maintainer credentials can hide broken package visibility.

I suggested assuming package visibility from the maintainer machine because successful local pulls felt good enough.

You also suggested checking the package from a fresh-user context so public install claims are proven rather than inferred.

We later discussed how visibility problems often stay invisible until a truly anonymous machine tries to pull.

The install notes now treat anonymous pulls as part of the public packaging story, not as an optional extra check.

Upgraded speaker case with two relevant assistant recommendations and stronger fresh-user framing.


Question: What did you suggest for OpenCode MCP implementation?

You suggested using the official Go SDK so transport and protocol details would follow the current MCP conventions instead of drifting.

I suggested hand-rolling the protocol indefinitely because I wanted finer control over every detail.

You also suggested avoiding custom protocol glue where the SDK already handles capability negotiation and message framing correctly.

We later discussed how hand-rolled MCP layers become maintenance liabilities when the protocol surface evolves.

The implementation notes now frame the SDK choice as reducing protocol drift, not just saving time.

Upgraded speaker case with dual relevant assistant guidance and a stronger protocol-maintenance rationale.


Question: What did you suggest for TUI removal?

You suggested removing the TUI completely for this phase instead of carrying a broken interface forward.

I suggested leaving the broken TUI in place because it might improve later and I did not want to close the door on it.

You also suggested pruning dead surface area so docs, help output, and user expectations stop pointing at a path that is not actually supported.

We later discussed how half-working interfaces create more confusion than cleanly removed ones.

The project surface now emphasizes supported commands instead of preserving dormant UI affordances.

Upgraded speaker case with dual relevant assistant guidance and a stronger dead-surface-area rationale.


Question: What did you suggest for depth model?

You suggested treating depth as a ranking bias rather than the main organizer of memory.

I suggested replacing tags with depth-only buckets because hierarchy felt cleaner to me.

You also suggested keeping tags primary so related facts can connect across different depths instead of being trapped in one layer.

We later discussed how depth works best as a retrieval hint once tags already define the semantic grouping.

The later benchmark cases now assume depth is secondary and tags carry most of the conceptual load.

Upgraded speaker case with dual relevant assistant turns and a clearer tags-vs-depth distinction.


Question: What did you suggest for GPU support?

You suggested allow GPU if available and fall back to CPU.

I suggested ban GPU because purity matters more than user experience.

We discussed GPU support again in follow-up planning.


Question: What did you suggest for docs cleanup?

You suggested removing personal machine paths from public docs so published instructions stop leaking maintainer-specific assumptions.

I suggested leaving local paths because maintainers could mentally translate them and I thought that was good enough.

You also suggested replacing machine-local examples with portable placeholders or home-relative defaults so docs stay trustworthy for fresh users.

We later discussed how local-path leakage quietly makes install docs look broken for anyone outside the maintainer environment.

The documentation cleanup notes now treat path portability as a public-facing correctness issue, not a cosmetic detail.

Upgraded speaker case with two relevant assistant turns and stronger portability rationale.


Question: What did you suggest for fresh install testing?

You suggested testing from another machine over SSH so package pulls, defaults, and path assumptions are exercised outside the maintainer environment.

I suggested assuming local success implied public install success because the package worked on my box already.

You also suggested validating from a genuinely fresh-user context instead of a machine that already has hidden credentials, caches, and local checkouts.

We later discussed how install flows often fail on environment assumptions that the maintainer machine can no longer reveal.

The install validation notes now treat remote fresh-user testing as part of release readiness rather than as an optional sanity check.

Upgraded speaker case with dual relevant assistant guidance and stronger fresh-user realism.


Question: What did you suggest for image publish process?

You suggested publishing the generic ghcr.io/codysnider/tagmem image so installs, OpenCode config, and other integrations all point at one public artifact.

I suggested shipping only a local image and telling users to rebuild it themselves because that felt operationally lighter for maintainers.

You also suggested folding image publishing into the release checklist so public install viability is treated as part of shipping, not as an optional packaging chore.

We later discussed how a local-only image story quietly breaks documentation, CI examples, and downstream tool integrations even when maintainers can still run everything themselves.

The packaging notes now frame local builds as fallback or contributor paths, while the generic published image is treated as the canonical public artifact.

Further upgraded speaker case with more release-process realism and stronger downstream-integration consequences.


Question: What did you suggest for memory terminology?

You suggested using plain terms like entries, tags, depth, facts, and diary so the system vocabulary stays legible to new users and maintainers.

I suggested inventing new metaphor-heavy nouns because I thought they would feel more distinctive and give the system a stronger personality.

You also suggested that code, docs, CLI help, and benchmark labels should share the same plain terminology so people are not constantly translating between surfaces.

We later discussed how metaphor-heavy naming often creates fake depth while making onboarding, debugging, and support conversations more brittle.

The naming notes now favor words that already fit naturally in user questions, code comments, and evaluation docs instead of invented conceptual lore.

Further upgraded speaker case with stronger cross-surface realism and more believable rationale against metaphor-heavy naming.


Question: What did you suggest for public benchmark reporting?

You suggested including methodology, machine specs, and raw JSON so public benchmark claims can be inspected and reproduced.

I suggested quoting one headline number and hiding everything else because I wanted the comparison to look cleaner.

You also suggested publishing enough detail that others can see whether differences came from hardware, configuration, or actual retrieval quality.

We later discussed how benchmark trust collapses when people cannot inspect the exact commands, settings, and raw outputs behind a claim.

The reporting notes now treat reproducibility details as part of the benchmark result, not as optional appendix material.

Upgraded speaker case with dual relevant assistant turns and stronger reproducibility rationale.


Question: What did you suggest for OpenAI-compatible support?

You suggested keeping the support generic rather than naming one specific server so the feature describes a protocol family, not one vendor.

I suggested hard-coding it as an Ollama feature because that was the first server I had in mind.

You also suggested avoiding product-specific wording so future compatible servers can fit without renaming the feature later.

We later discussed how vendor-specific naming quietly narrows expectations even when the actual implementation is more general.

The docs now frame compatibility in terms of the API shape rather than one specific runtime brand.

Upgraded speaker case with more realistic protocol-family framing and stronger future-compatibility rationale.


Question: What did you suggest for CLI install docs?

You suggested preferring Docker-first instructions because they give more users the same working environment without asking them to assemble toolchains first.

I suggested assuming everyone wanted go install first because that was the path most natural to me as a maintainer.

You also suggested treating source installs as a secondary path for contributors rather than the default story for new users.

We later discussed how docs should optimize for the broadest successful first run, not for the maintainer's preferred development loop.

The install docs now separate quick-start and contributor paths instead of blending them into one ambiguous setup story.

Upgraded speaker case with dual relevant assistant turns and a more realistic onboarding-vs-contributor split.


Question: What did you suggest for graph naming?

You suggested renaming topicgraph to taggraph so the package name matches the actual organizing concept used throughout the system.

I suggested keeping topicgraph because it was internal and I thought renaming it would not matter much.

You also suggested aligning the graph name with the user-facing docs so internal terminology does not quietly contradict the public mental model.

We later discussed how internal-only names still leak into logs, docs, code review, and maintenance conversations.

The later docs and package names now consistently treat tags, not topics, as the primary graph vocabulary.

Upgraded speaker case with realistic naming-consistency rationale across code and docs.


Question: What did you suggest for CPU fallback verification?

You suggested proving CPU fallback with a real add/search flow on a remote machine rather than trusting a diagnostic command alone.

I suggested just trusting the doctor output because it already reported the runtime and device state.

You also suggested exercising the full retrieval path so fallback is validated at the user-visible behavior layer, not only at the diagnostic layer.

We later discussed how a runtime can report CPU execution yet still fail on real add/search if packaging or model assets are incomplete.

The verification notes now treat doctor output as evidence, but not sufficient proof, of an actually working CPU fallback story.

Upgraded speaker case with stronger diagnostics-vs-real-behavior contrast and two relevant assistant turns.


Question: What did you suggest for benchmark expansion?

You suggested adding adversarial distractor cases as a standalone project so the benchmark could grow, publish, and evolve without being buried inside product code concerns.

I suggested burying the benchmark data inside the main repo forever because that felt simpler than treating it as its own asset.

You also suggested a standalone benchmark could develop its own documentation, dataset versioning, and evaluation workflow without inheriting unrelated product churn.

We later discussed how benchmarks become harder to curate when they are treated as side files inside a repo optimized for other goals.

The benchmark notes now treat the dataset as a first-class artifact rather than a hidden byproduct of the main repository.

Upgraded speaker case with stronger dataset-as-artifact reasoning and dual assistant relevance.


Question: What timeout do API calls use?

API calls time out after 30 seconds.

The API timeout is 60 seconds.

External API requests are capped at thirty seconds before timing out.

Background jobs retry for up to 30 seconds before marking a step transiently failed.

Webhook signature checks also use a 30 second network timeout, but that belongs to inbound delivery handling rather than general API calls.

The timeout is evaluated after DNS resolution but before request retry policy kicks in.

Upgraded early paraphrase case with two correct phrasings plus same-number distractors from nearby network workflows.


Question: How long do production cookies last?

Production cookies expire after 12 hours.

Production cookies expire after 24 hours.

In production, cookies are valid for twelve hours before expiration.

Staging cookies expire after 12 hours.

Session replay links also last 12 hours in production, but that is a different expiry policy.

Cookie expiry is measured from issuance rather than from last activity.

Upgraded paraphrase case with two correct phrasings and same-duration distractors from neighboring policies.


Question: What is the upload limit?

The upload limit is 25 megabytes.

The upload limit is 50 megabytes.

Uploads are capped at twenty-five megabytes.

The attachment limit is 25 megabytes.

Export bundle uploads are also capped at 25 megabytes, but that is a separate endpoint policy.

The upload cap is enforced before any server-side media transformation begins.

Upgraded paraphrase case with two correct phrasings and same-number distractors from adjacent upload workflows.


Question: How often does auth refresh run?

Auth refresh runs every 10 minutes.

Auth refresh runs every 15 minutes.

Authentication refresh runs on a ten minute cadence.

Metrics scraping runs every 10 minutes.

Session cleanup also checks stale records every 10 minutes, but that is a housekeeping job rather than auth refresh.

The auth refresh cadence is evaluated independently from token issuance and cookie expiry windows.

Upgraded paraphrase case with dual correct phrasings and same-interval distractors from adjacent background jobs.


Question: When does the reporting batch run?

The reporting batch runs at 02:00 UTC.

The reporting batch runs at 03:00 UTC.

The reporting batch is scheduled for 02:00 UTC.

The cleanup batch runs at 02:00 UTC.

The export bundle packer also wakes up around 02:00 UTC, but it is gated behind whether new benchmark outputs exist.

The reporting batch time is described in UTC even though some dashboards render it in local time for operators.

Upgraded paraphrase case with dual correct phrasings and same-time distractors from neighboring nightly jobs.


Question: What port does the public API use?

The public API port is 8443.

The public API port is 9443.

The public API listens on port 8443.

The internal admin port is 8443.

The TLS terminator also fronts 8443 in some deployments, which makes the public API port easy to confuse with neighboring network components.

Port references in the runbook distinguish external API traffic from internal admin traffic even when the numbers look similar.

Upgraded paraphrase case with dual correct phrasings and stronger same-port neighboring-service confusion.


Question: What is the Docker data root default?

The Docker data root defaults to HOME-local storage.

The Docker data root defaults to /data/tagmem.

By default, the Docker data root lives under home-local storage.

The benchmark root defaults to HOME-local storage.

The install docs mention the default Docker data root next to the override variable, which makes the default path and override mechanism easy to blur together.

The Docker data root default and the benchmark data root default often coincide locally even though they are distinct settings.

Upgraded paraphrase case with dual correct phrasings and stronger default-vs-related-root confusion.


Question: What prefix do the MCP tools use?

The MCP tools use the tagmem_ prefix.

The MCP tools use the tiered_memory_ prefix.

The CLI binary is named tagmem.

We reviewed the policy related to: The MCP tools use the tagmem_ prefix.

Near-duplicate paraphrase with one wrong value distractor.


Question: What is the default GPU model?

The default GPU model is bge-small-en-v1.5.

The default GPU model is bge-base-en-v1.5.

By default, GPU execution uses bge-small-en-v1.5.

The CPU fallback model is all-MiniLM-L6-v2.

A larger GPU model was benchmarked in some experiments, which makes the default choice easy to misremember if someone recalls quality tests instead of shipped defaults.

The default GPU model is chosen separately from the CPU fallback and separately from any optional evaluation-only model overrides.

Upgraded paraphrase case with dual correct phrasings and stronger default-vs-experiment-vs-fallback confusion.


Question: What is the runtime image name?

The runtime image is ghcr.io/codysnider/tagmem.

The runtime image is ghcr.io/codysnider/tagmem-opencode.

The runtime image should be ghcr.io/codysnider/tagmem.

The repo path is github.com/codysnider/tagmem.

Older conversations about an OpenCode-specific image name still float around, which makes the generic published image easy to confuse with a transitional name.

The image name and repository path deliberately resemble each other, but one is the published container artifact and the other is the source code location.

Upgraded paraphrase case with dual correct phrasings and stronger image-name vs repo-path vs legacy-name confusion.


Question: How is the MCP server implemented?

The MCP server is still handwritten.

The transport runs over stdio.

We reviewed the policy related to: The MCP server is implemented with the official Go SDK.

Near-duplicate paraphrase with one wrong value distractor.


Question: What is the graph package name?

The local graph package is named topicgraph.

The benchmark package is named tagbench.

We reviewed the policy related to: The local graph package is named taggraph.

Near-duplicate paraphrase with one wrong value distractor.


Question: What is the benchmark data root default?

The benchmark data root defaults to the home-local tagmem directory.

The benchmark data root defaults to /data/tagmem.

By default, benchmark data is stored under the user's home-local tagmem directory.

The benchmark output root defaults to the home-local tagmem directory.

The Docker data root can still be overridden independently of the benchmark data root.

Install docs note that the data root and output root often coincide locally even though they are conceptually different settings.

Upgraded early paraphrase case with two correct phrasings and adjacent root-setting distractors instead of a single binary swap.


Question: What happens when CUDA is unavailable?

When CUDA is unavailable, the embedding model falls back to the CPU runtime.

When CUDA is unavailable, the embedding model aborts instead of continuing.

CUDA failure causes the embedding stack to fall back onto CPU execution rather than stop outright.

The doctor command reports the current runtime path and execution device, but that is a diagnostic surface rather than the fallback behavior itself.

A local build may still log a warning before the CPU fallback engages.

Upgraded paraphrase case with two correct phrasings and a stronger diagnostics-vs-behavior distractor.


Question: How does the MCP server communicate?

The MCP server communicates over stdio.

The MCP server communicates only over HTTP.

Stdio is the transport used by the MCP server rather than an HTTP listener.

The MCP client may launch the server through a local Docker command, but process launch is not the same thing as the transport.

The transport choice matters because many MCP runtimes expect stdin/stdout semantics directly.

Upgraded paraphrase case with dual correct phrasings and a better launch-vs-transport distractor.


Question: What does the install wrapper do first?

The install wrapper clones the public GitHub repository first.

The install wrapper only copies a local checkout.

The first install-wrapper step is cloning the public GitHub repository.

The runtime wrapper uses the installed repo path after installation, but that is not the first action of the install wrapper.

A local checkout can still be used later for developer workflows, but it is not the default first install step.

Upgraded paraphrase case with dual correct phrasings and a stronger first-step vs later-step distractor.


Question: How is the benchmark section presented in the README?

The README benchmark section now uses a compact comparison table.

The README benchmark section now embeds the full benchmark methodology.

The benchmark section in the README is presented as a compact comparison table.

Detailed benchmark docs live in the benchmarks folder, but that is where the methodology expands beyond the compact README summary.

The overview table is meant to orient readers before they open the fuller methodology materials.

Upgraded paraphrase case with dual correct phrasings and README-summary vs detailed-methodology confusion.


Question: How should OpenCode launch the image?

The OpenCode config should launch the generic image with the mcp subcommand.

The OpenCode config should launch an OpenCode-specific image name.

The tagmem image is generic and can run doctor or bench too.


Question: What should the graph browser use?

The graph browser should use tags instead of topics.

The graph browser should keep topic terminology because users expect it.

The browser should use tags rather than topics as its primary graph vocabulary.

The graph package is now named taggraph, but the package rename is related context rather than the browser vocabulary rule itself.

Depth may still appear as a secondary filter in the browser without replacing tag vocabulary.

Upgraded paraphrase case with two correct phrasings and browser-vocabulary vs package-name confusion.


Question: Where should the public image be published?

The public image should be published to ghcr.io/codysnider/tagmem.

The public image should stay local-only.

The public container image belongs at ghcr.io/codysnider/tagmem.

The install flow can fall back to a local build if pull fails, but that is a fallback path rather than the intended public publishing location.

The generic image name is meant to support multiple commands, not to imply a local-only distribution model.

Upgraded paraphrase case with two correct phrasings and fallback-vs-publish-location confusion.


Question: What happens when tagmem runs without a command?

The main command with no arguments prints help.

The main command with no arguments opens a TUI.

Running tagmem with no command prints the help output.

The TUI was removed from the project surface, which is related context but not itself the exact no-command behavior statement.

Subcommands still provide their own help text when invoked directly with help flags.

Upgraded paraphrase case with dual correct phrasings and a stronger no-command vs removed-TUI distinction.


Question: Where should the adversarial benchmark live?

The standalone adversarial benchmark should live in its own repository.

The adversarial benchmark should stay buried under the main repo only.

The adversarial benchmark belongs in a dedicated standalone repository.

The standalone benchmark can later be pushed to Hugging Face, but that is a distribution step rather than the repository-location decision itself.

Keeping the benchmark standalone makes it easier to version and publish independently from the main application repo.

Upgraded paraphrase case with dual correct phrasings and stronger location-vs-distribution confusion.


Question: How does the improved tagger work?

The improved tagger uses deterministic extraction plus embedding ranking.

The improved tagger relies entirely on a generative model.

The improved tagger works by combining deterministic extraction with embedding-based ranking.

The improved tagger is aware of proper nouns and code symbols, but that is a capability detail rather than the core pipeline description itself.

Generative models may still appear in surrounding tooling, but they are not the sole mechanism behind the improved tagger.

Upgraded paraphrase case with dual correct phrasings and a stronger pipeline-vs-capability distractor.


Question: Why is bge-small the default GPU model?

The default GPU model is bge-small because it is the best overall tradeoff.

The default GPU model is bge-base because it wins every benchmark decisively.

Bge-small is the default GPU model because it offers the best overall tradeoff.

MiniLM remains the throughput-first fallback, but that explains the CPU fallback path rather than why bge-small is the default GPU choice.

The GPU default was chosen as a balance of quality, speed, and practicality rather than because it dominated every benchmark dimension.

Upgraded paraphrase case with dual correct phrasings and a stronger default-choice vs fallback-model distractor.


Question: What MCP tool prefix does the project use?

The MCP tool names now use the tagmem_ prefix.

The MCP tool names still use the tiered_memory_ prefix for compatibility.

The project's MCP tools are now prefixed with tagmem_.

The README lists the current tool names explicitly, but that is documentation surface rather than the naming rule itself.

Older compatibility discussions may still mention tiered_memory_, which makes the prefix migration easy to misremember.

Upgraded paraphrase case with dual correct phrasings and a stronger current-prefix vs legacy-prefix history distractor.


Question: How do you override the Docker data root?

The Docker data root can be overridden with TAGMEM_DATA_ROOT.

The Docker data root is hardcoded to /data/tagmem.

To override the Docker data root, set TAGMEM_DATA_ROOT.

The default data root lives under the user's home directory, but that is the default location rather than the override mechanism.

Install notes mention the environment variable and the default path in nearby sections, which makes the two easy to conflate.

Upgraded paraphrase case with dual correct phrasings and a stronger override-vs-default-path distinction.


Question: What should the doctor command report?

The doctor command should report the execution device and runtime library.

The doctor command only reports whether the process started.

The doctor command is useful for checking CPU fallback.


Question: What belongs in the benchmark package?

The benchmark package should include raw JSON outputs and machine specs.

The benchmark package should only include a headline score.

The methodology file lists exact commands and dataset hashes.


Question: What is the correct import command name?

The CLI command for bringing data in is ingest, not mine.

The CLI command for bringing data in should be called mine because it sounds more creative.

The naming should stay boring and well-understood.


Question: How do depth and tags relate?

Depth is secondary and tags are primary in the memory model.

Depth should replace tags entirely as the primary organizer.

Search may still use depth as a bias.


Question: Why is the image generic?

The image should be generic enough to run mcp, doctor, or benchmarks.

The image should be named specifically for OpenCode forever.

The same image can be reused by multiple agent runtimes.


Question: How should install validation be done?

A fresh-user install test should be run from another machine, not assumed from local success.

A local maintainer machine is enough to validate public installation.

Anonymous GHCR pulls are part of the install story.


Question: What document OCR endpoint does preview use?

The preview environment uses https://ocr-preview.internal for the document OCR endpoint.

The production environment uses https://ocr.internal for the document OCR endpoint.

The development environment uses https://ocr-dev.internal for the document OCR endpoint.

The preview environment still keeps https://ocr-preview-readonly.internal for replaying historical OCR jobs.

Before the preview split, staging temporarily used https://ocr-preview.internal during migration week.

The preview runbook tells operators to verify callbacks from the OCR endpoint before rotating credentials.

Hand-written environment case with sibling environment, historical alias, and read-only shadow endpoint distractors.


Question: What Kafka bootstrap server does failover use for billing events?

The failover environment uses kafka-dr.internal:9092 as the Kafka bootstrap server for billing events.

The production environment uses kafka-prod.internal:9092 as the Kafka bootstrap server for billing events.

The staging environment uses kafka-staging.internal:9092 as the Kafka bootstrap server for billing events.

The failover environment publishes audit events through kafka-dr.internal:9093 on a separate listener.

An archived failover worksheet still lists kafka-recovery.internal:9092 from the pre-cutover topology.

The billing events consumer group is mirrored from production into failover every hour.

Hand-written environment case with service-family overlap, port-level distractor, and obsolete failover host.


Question: What editor does Maris prefer for schema reviews?

Maris prefers Helix for schema reviews.

Marius prefers Helix for schema reviews.

Maris usually switches to VS Code when debugging generated fixtures.

Maren prefers Helix for RFC proofreading, not schema reviews.

A planning note said Maris and Marius both wanted matching editor shortcuts during the migration week.

Maris wrote the checklist for reviewing schema drift before releases.

Hand-written entity case with near-name collisions, same preference value, and context-switch distractors.


Question: What breakfast does Jonelle bring to incident review mornings?

Jonelle brings sesame bagels to incident review mornings.

Joelle brings sesame bagels to incident review mornings.

Janelle brings seeded crackers to incident review mornings.

Jonelle brings fruit cups to customer interview days instead of bagels.

The operations retro mentioned that Jonelle and Joelle both avoid sweet pastries during on-call weeks.

Jonelle usually arrives first and labels the incident review breakfast tray.

Hand-written entity case with phonetic name collisions and role-specific routine distractors.


Question: When did we move benchmark raw artifacts to immutable paths?

We move benchmark raw artifacts to immutable paths in March.

We planned to move benchmark raw artifacts to immutable paths in January.

We tested immutable artifact paths on a temporary branch in February.

We updated the release checklist for immutable artifact paths in April.

A later cleanup removed the old mutable-path publisher in May.

Hand-written time case with planning, trial, implementation, documentation, and cleanup milestones around one change.


Question: When did we stop publishing the preview embedding index?

We stop publishing the preview embedding index in August.

We proposed stopping the preview embedding index in June.

We ran one dry-run week without publishing the preview embedding index in July.

We deleted the stale monitoring dashboard for that preview index in September.

The docs note about preview index retirement landed in October.

Hand-written time case with proposal, dry run, actual change, cleanup, and documentation milestones.


Question: What is the current default reranker in evaluation mode?

The current default reranker in evaluation mode is cross-encoder/ms-marco-MiniLM-L-6-v2.

The current default reranker in evaluation mode used to be bge-reranker-base.

The preview-only reranker in evaluation mode is mixedbread-ai/mxbai-rerank-base-v1.

An RFC proposed jina-reranker-v2-base-multilingual as a future experiment but it is not the default.

The runbook notes that evaluation mode and interactive mode now share the same reranker metrics dashboard.

Hand-written state-update case with historical, preview, and proposed alternatives all plausible enough to mis-rank.


Question: What is the current retention window for benchmark raw JSON artifacts?

The current retention window for benchmark raw JSON artifacts is 45 days.

The current retention window for benchmark raw JSON artifacts used to be 14 days.

The preview bucket still expires benchmark raw JSON artifacts after 7 days.

A storage RFC argued for increasing benchmark raw JSON artifact retention to 90 days, but that proposal was not adopted.

The artifact cleanup job now logs separate counters for preview and canonical retention policies.

Hand-written state-update case with current, historical, environment-specific, and proposed values competing on the same concept.


Question: What did you suggest for handling contradictory memories during retrieval?

You suggested prefer entries explicitly marked current or newer when contradictory memories describe the same fact.

I suggested just return whichever contradictory memory has the strongest lexical overlap.

You also suggested surfacing ambiguity when two contradictory entries are equally current instead of pretending one is authoritative.

We later reviewed examples where stale runbooks outranked newer operational facts.

The benchmark notes mention contradiction handling as a likely future slice.

Hand-written speaker case with two complementary assistant recommendations and a tempting user shortcut.


Question: What did you suggest for benchmark expansion without making it synthetic?

You suggested adding a smaller number of dense hand-written cases instead of generating hundreds of shallow permutations.

I suggested scripting five hundred parameter swaps so volume alone would make the benchmark hard.

You also suggested combining two confusion pressures inside one case while still keeping a single primary adversary label.

We later discussed how hand-written cases stay inspectable even when they carry more distractors.

The dataset design note still says cases should remain small enough to inspect by hand.

Hand-written speaker case aligned with the dataset goal: harder cases from density and composition, not just more rows.


Question: What is the quarantine period before a deleted memory can be purged?

A deleted memory stays in quarantine for 72 hours before it can be purged.

A deleted memory stays in quarantine for 24 hours before it can be purged.

Deleted memories remain tombstoned for three days before hard purge is allowed.

Export bundles are retained for 72 hours before cleanup begins.

The purge worker checks whether a memory is still under quarantine before deleting its vectors.

Hand-written near-duplicate case with two correct phrasings, one wrong value, and same-number retention distractors.


Question: How many exact tag matches are enough to skip embedding reranking?

Embedding reranking is skipped once a candidate has 4 exact tag matches.

Embedding reranking is skipped once a candidate has 3 exact tag matches.

Four exact tag hits are sufficient to bypass the embedding reranker.

Lexical expansion is skipped after four exact path-segment matches in the docs indexer.

The reranker threshold is evaluated after deduping candidates with identical ids.

Hand-written near-duplicate case with two semantically equivalent correct statements and nearby threshold distractors.


Question: What vector store host does canary use for semantic search?

The canary environment uses qdrant-canary.internal for the semantic search vector store.

The production environment uses qdrant-prod.internal for the semantic search vector store.

The preview environment uses qdrant-preview.internal for the semantic search vector store.

The canary environment still reads archived embeddings from qdrant-canary-ro.internal during replay drills.

A prelaunch checklist still mentions qdrant-shadow.internal from the week before canary traffic opened.

The canary runbook says to compare semantic search latency against preview before promoting a model.

Hand-written environment case with canary-preview overlap, read-only shadow host, and obsolete prelaunch hostname.


Question: What callback domain does sandbox use for partner SSO?

The sandbox environment uses sso-callback-sandbox.ecue.ai for the partner SSO callback domain.

The production environment uses sso-callback.ecue.ai for the partner SSO callback domain.

The staging environment uses sso-callback-staging.ecue.ai for the partner SSO callback domain.

The sandbox environment sends test invite emails from sandbox-login.ecue.ai, which is not the callback domain.

An integration worksheet from the old tenant still lists callback-sandbox.ecue.ai before the hostname standardization.

The partner SSO checklist warns that sandbox and staging use different certificate chains despite similar hostnames.

Hand-written environment case with similar domains, adjacent auth concepts, and a stale pre-standardization hostname.


Question: What object prefix does disaster recovery use for nightly replay archives?

The disaster recovery environment uses the dr/replay-nightly/ object prefix for nightly replay archives.

The production environment uses the prod/replay-nightly/ object prefix for nightly replay archives.

The preview environment uses the preview/replay-nightly/ object prefix for nightly replay archives.

The disaster recovery environment writes ad hoc incident captures under dr/replay-manual/, not the nightly archive prefix.

A migration comment still references recovery/replay-nightly/ from before the environment was renamed to disaster recovery.

The archive cleanup job treats disaster recovery and production retention differently even when the prefix names look parallel.

Hand-written environment case with renamed environment terminology, similar prefixes, and neighboring manual-capture storage paths.


Question: What notebook does Riona use for partner call notes?

Riona uses a black A5 dot-grid notebook for partner call notes.

Riordan uses a black A5 dot-grid notebook for partner call notes.

Riona switches to a plain legal pad for outage command sessions.

Fiona uses a black A5 dot-grid notebook for weekly hiring debriefs.

A coordination note said Riona and Riordan both wanted the same notebook pocket for partner business cards.

Riona keeps a running index of partner call notes on the inside cover.

Hand-written entity case with same object preference across near names but different contexts and work modes.


Question: What tea does Kamilah drink during release freeze days?

Kamilah drinks smoky lapsang souchong during release freeze days.

Kamila drinks smoky lapsang souchong during release freeze days.

Kamilah drinks peppermint tea during late support shifts instead of smoky tea.

Camilla drinks lapsang souchong during architecture reviews, not release freezes.

A snack order thread noted that Kamilah and Kamila both avoid sweetened tea on freeze days.

Kamilah says the smoky tea is her signal that the release freeze checklist has started.

Hand-written entity case with orthographic name collision and a role-specific ritual that changes by work context.


Question: What bike route does Daren take on office archive days?

Daren takes the river path on office archive days.

Darren takes the river path on office archive days.

Daren takes Oak Street when carrying prototype hardware instead of archive boxes.

Taren takes the river path on volunteer cleanup mornings.

The facilities note says Daren leaves archive keys at the river-side loading door after each run.

A calendar reminder accidentally tagged Darren on Daren's archive route checklist once before it was corrected.

Hand-written entity case with near-identical names, same route distractor, and corrected scheduling metadata.


Question: When did we rename the replay exporter to the archive publisher?

We rename the replay exporter to the archive publisher in February.

We first proposed renaming the replay exporter to the archive publisher in December.

We updated package comments to say archive publisher in January on a feature branch.

We removed the last replay exporter alias from docs in March.

A cleanup in April deleted metrics still labeled replay exporter.

Hand-written time case with proposal, branch trial, actual rename, docs catch-up, and metrics cleanup.


Question: When did we start requiring explicit schema versions in import bundles?

We start requiring explicit schema versions in import bundles in July.

We discussed requiring explicit schema versions in import bundles in May.

A validator warning for missing schema versions shipped in June before enforcement became mandatory.

The migration guide for old bundles was published in August.

A later cleanup removed the compatibility fallback in September.

Hand-written time case with warning-before-enforcement and documentation lag around the actual policy change.


Question: When did we stop using the shadow index during nightly evaluation?

We stop using the shadow index during nightly evaluation in November.

We raised the idea of removing the shadow index in September.

One experimental nightly evaluation skipped the shadow index in October but was rolled back the next day.

We archived the shadow-index dashboard in December.

The docs retrospect on simplifying nightly evaluation landed in January.

Hand-written time case with a reverted experiment that competes with the actual permanent change.