Skip to main content

TODOs

Open documentation and engineering items. Each item is verified against the current source at the date of last audit (see commit history).

Engineering items (real code work)

  • create_shift → canonical endpointfunctions/pivotAiAgent/tools/schedule/createShift.ts:1 has an active TODO(refacto-endpoint) comment. The tool writes WeeklySchedule/{cid}/{date} directly via Firebase REST. The schedule module's POST /shifts only creates drafts (requires scheduleId); a "create published shift" endpoint doesn't exist yet.
  • Orphan reconciler — verified absent. Grep for "reconcil" in functions/modules/ai-memory and functions/pivotAiAgent returns zero hits. Recovery from temporalScheduled: false is still a manual frontend re-PATCH.
  • Provider fallback — verified absent. functions/pivotAiAgent/providers/index.ts is a 22-line switch on req.provider; no retry/fallback to the alternate provider on error.
  • Rate limiting — verified absent. Grep for "rate limit"/"rateLimit" across functions/shared, functions/pivotAiAgent, functions/modules returns zero hits. The only current backstop is the LLM provider's own quota plus the admin-controlled per-company AI config override.
  • Audit logging — partially absent. A ScheduleAuditLog/{cid}/{date} RTDB path exists (legacy, schedule-specific). No audit log covers MIA actions (rules, memory updates, cron tasks, document uploads). Adding an AuditLog/{ts} with action, actor, resource, before, after would close the gap.
  • Postgres migration for MIA tables — verified: no MIA-specific PG tables. Grep for kysely/cloud-sql combined with MIA collection names returns zero. Several onXxxPgSync Pub/Sub listeners propagate non-MIA records (companies, users, employees, schedule). Decide which MIA data moves to PG (likely usage logs + audit) vs. stays in RTDB (sessions, memory).
  • Feature flag system — verified absent. Grep for FeatureFlags/featureFlags returns zero. The closest thing is Companies/{cid}/aiConfig + GlobalAiConfig (per-company / global LLM provider+model override) — useful as a per-company kill-switch for the AI model but not a general flag mechanism.
  • Consolidate inline OpenAPI schemas into common/dtos/calculator, pos-sync, onboarding, and integration-engine schemas are mirrored inline in functions/modules/docs/logic/registry.ts (committed as pivot@c7ca42e4c and pivot@7eb1bd7ec). Moving them to common/dtos/<module>/ would match the pattern used by auth, requests, and the other already-clean modules. Prevents drift when the runtime schemas change.
  • Implement search_tools meta-tool (or remove the aspirational comment)functions/pivotAiAgent/tools/index.ts:2-8 describes on-demand tool discovery via a search_tools meta-tool. buildToolSet() ignores its categories argument and returns all definitions. Either build the meta-tool or strip the comment.
  • Naming consistency: Finn → Mia — 32 occurrences in functions/pivotAiAgent/ARCHITECTURE.md, 10 in FIREBASE_MIGRATION.md, multiple in FIREBASE_SCHEMA.md and functions/pivotAiAgent/docs/. Production reverse-proxy hostname is finn.sauvecorp.tech. The RTDB collection is AIZackboardSessions/ (typo of "Dashboard"). The aiAgentPersona field also has 'zack' as an option alongside 'Mia'. Pick canonical names for code vs. user-facing surfaces, then scrub the in-service docs.
  • Server-enforced Mia access — today the per-manager allowlist at Companies/{cid}/pivotAiAgentAccess/{userId} is a frontend gate only. The chat endpoint /api/chat doesn't check it. A determined manager could bypass the UI and still call the AI. Either enforce on the Cloud Run service (read the allowlist before processing the request) or accept it as "UI gate is enough" and document the trust model explicitly.

Resolved since the last audit

The following items were on the list previously and have been confirmed resolved or were never actually missing:

  • Register calculator, requests, pos-sync, onboarding, and docs itself in OpenAPI → Done in pivot@c7ca42e4c.

  • Register auth and integration-engine in OpenAPI → Done in pivot@7eb1bd7ec. All 17 modules + 2 sibling Hono systems now appear in the spec.

  • Follow-up: move the inline schemas into common/dtos/ (still listed as engineering work above).

  • Where AI usage is persisted → Documented: AiUsageLogs/{companyKey}/{day}/{rowId} in RTDB. See Token & Cost Tracking.

  • miaSettings field enumeration → That path doesn't exist in the codebase. Per-company AI config lives at Companies/{cid}/aiConfig instead. Earlier docs that mentioned miaSettings were corrected.

  • pageContext schema → Documented: { label?, path?, selectedEmployeeName?, selectedEmployeeId? }. See Normal Conversations.

  • Token expiry in Temporal → Confirmed: getServiceTokenActivity at functions/pivotAiAgent/temporal/activities.ts refreshes the user's token via getServiceToken when it has expired mid-workflow.

Documentation gaps remaining

  • Production Temporal setup — namespace, TLS certs, authentication for production Temporal. The dev-2 setup is self-hosted at localhost:7233. Update Temporal and Operations once production config is documented.
  • Legacy endpoint inventoryfunctions/http/**, functions/cron/**, functions/dashboard/**, functions/on-call/** aren't in the OpenAPI spec and these docs only mention them in aggregate. If any of them are MIA-relevant (today's 60 tools don't call them), document them.
  • Frontend ↔ tool ↔ endpoint trace — pick one frontend feature (e.g. "send a tip rule from MiaTips") and trace the full path: frontend component → chat request → tool call → internal endpoint → RTDB write. Useful onboarding artifact.