Carol — back to Apps ← Apps

Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999900239
📋

CAROL-INI-2007-00: Reliable visit-duration tracking + unique-visitor dedup for admin visit stats

Initiative
Open in Initiatives →

📖About

Duration captured only on unreliable page-exit beacon; visitor total counts every visit row. Fix: heartbeat duration (15s + visibilitychange) with server MAX update; persistent visitor_id cookie for unique-visitor dedup shown separate from page views. Touches auth app (schema+endpoint+cookie), injected tracking script, admin counting UI.

⚖️Decisions

  • Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
  • [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • INI-1767 compliance gate refused close — CAROL-INI-1767 compliance gate refused close: [admin] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [admin] design: dark-theme baseline palette not used — design #178 §1; [auth] design: dark-theme baseline palette not used — design #178 §1; [auth] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [auth] design: no empty state — handle the no-data case (design #178 §3). Bring the app to standard (Design System #178 / architecture #146/#173/#156), or add a decision row prefixed 'Compliance waived by' to override. (shared.bypass.bypass_end[INI-1767])
  • [status-router] executing -> blocked | event=bypass_blocked | bypass transition (or-bx-01)
  • Bypass session failed — initiative blocked (exec 353) — bypass_end called with success=False for exec 353, run 710 (shared.bypass.bypass_end)
  • Compliance waived by Orion: pre-existing design-system gaps unrelated to this change — This bypass only touches visit-tracking logic (the visit-log endpoint + schema in the auth/access-management app, the injected tracking script, and the admin visit-stats counting). The gate flags (missing canonical topbar, dark-theme baseline palette, loading/empty states in the admin and auth apps) are pre-existing Design System #178 gaps that predate this change and are out of scope; they should be addressed in a dedicated design-compliance initiative for those apps. (orion)
  • [status-router] blocked -> executing | event=operator_reopen | reopen to deploy+restart after compliance waiver; work done and twin-reviewed (orion)
  • [status-router] executing -> dispatched | event=dispatch | dispatcher queued (ds-s1)
  • [status-router] dispatched -> reviewing | event=operator_finalize | code deployed (access-management+gateway restarted), twin-review passed; heartbeat JS rolls out per-app (orion)
  • UAT: Total visits per day chart shows a green line for logged-in visitors — Ninad UAT comment; implemented as a second green line dataset on the visits line chart (admin served fresh, no restart). (orion)
  • UAT: Total visit time per day shows logged-in time as a green stacked segment on top of anonymous — Ninad UAT comment; bar restructured into Anonymous (base) + Logged-in (green) stacks. (orion)
  • [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

Success criteria

  • Visit duration is captured via periodic heartbeats so most visits (including mobile) record a non-null duration, not just exit-beacon survivors (must_have)
  • Server updates duration_ms to MAX(existing, incoming) so heartbeats only grow the time (must_have)
  • A persistent visitor_id cookie identifies returning browsers; unique visitors counted by visitor_id (email when signed in) (must_have)
  • Admin shows unique-visitor count distinct from total page views (must_have)