> ## Documentation Index
> Fetch the complete documentation index at: https://mako-docs.devinagiffy.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Pivot Roadmap: Accountability Bot
> Comprehensive plan to pivot Hitler from generic workplace intelligence to a strict accountability bot for Inagiffy's content marketing team
This document is the single source of truth for the Hitler v2 pivot. It maps every PRD requirement
to current codebase state, identifies gaps, and defines the implementation plan. **Last updated:
March 2026.**
## Executive Summary
Hitler is pivoting from a **generic multi-tenant workplace intelligence platform** to a **strict, opinionated accountability bot** purpose-built for Inagiffy's 10-person content marketing agency. The bot will automate daily task tracking rituals in Slack, enforce accountability through a card system, generate layered reports (public + private), and add a journaling layer for early blocker/wellbeing detection.
### What Changes
| Aspect | Current (v1) | Target (v2) |
| -------------- | ------------------------------ | ------------------------------------------------------------ |
| Audience | Any organization | Inagiffy's 10-person content team |
| Task flow | User tells bot, draft, confirm | Morning thread, team posts tasks, bot tracks all day |
| Task model | Generic title/priority/due | Typed + sized (S/M/L) + weighted + client-tagged |
| Accountability | Flags (wellbeing-based) | Card system (yellow/red) + carry-forward escalation |
| Reports | Real-time analytics dashboard | Scheduled daily/weekly/monthly reports (public + private) |
| Clients | Not tracked | First-class entity with deploy schedules and health tracking |
| Bot role | Conversational assistant | Strict process enforcer + report generator |
### What Stays
* Bot-first architecture (Slack as primary interface)
* NestJS API as single source of truth
* Drizzle ORM + PostgreSQL
* BullMQ job system + Redis
* LLM for natural language parsing (task classification, OOO parsing)
* Human-in-the-loop confirmation for task creation
* SDK for bot-to-API communication
* Multi-tenant foundation (even if single-tenant now, keeps future optionality)
***
## Gap Analysis: PRD vs Current Codebase
### Legend
* **EXISTS** = Feature is built and working
* **PARTIAL** = Some foundation exists but needs significant changes
* **NEW** = Needs to be built from scratch
### Feature-by-Feature Breakdown
| # | PRD Feature | Status | Current State | What Needs to Change |
| -- | ---------------------------------- | ----------- | -------------------------------------------- | --------------------------------------------------------------------------- |
| 1 | Morning Thread (9 AM) | **NEW** | No thread management exists | New cron, Slack thread creation, reply tracking |
| 2 | Task Submission Deadline (11 AM) | **NEW** | No submission tracking | Cron to scan thread replies, cross-ref roster, issue cards |
| 3 | Auto-Classification Engine | **PARTIAL** | LLM parses tasks but no type/size/client | Add task-type keyword map, size/weight system, client matching |
| 4 | End-of-Day Collection (5-7 PM) | **NEW** | No status collection from threads | Thread scanning, emoji/status parsing, carry-forward logic |
| 5 | Daily Reports (Public + Private) | **NEW** | Only real-time analytics dashboard | Report generation service, public/private channel posting |
| 6 | Weekly Reports | **NEW** | No scheduled reports | KPI comparison engine, card tallies, client health |
| 7 | Thursday Check-In | **PARTIAL** | Mood check-in exists but different purpose | Repurpose to KPI-based underperformer detection + DM |
| 8 | Monthly Report | **NEW** | No monthly reporting | Trend analysis, scalability assessment, action items |
| 9 | Card System (Yellow/Red) | **NEW** | Flags exist but different concept | New DB tables, card logic, DM notifications, weekly reset |
| 10 | Ops Bulk-Tagging | **NEW** | No classification review UI | Slack interactive messages for ops review |
| 11 | Invisible Labor Logging | **NEW** | No intervention tracking | /log-intervention command, attribution, reporting |
| 12 | Positive Reinforcement | **NEW** | No shoutouts or rewards | Daily/weekly/monthly recognition system |
| 13 | Client-Level Grouping | **NEW** | Projects exist but not clients | New client entity, deploy schedules, health tracking |
| 14 | Blocker Escalation | **NEW** | No blocker tracking | /blocked, /unblocked, escalation timeline |
| 15 | Onboarding Ramp-Up | **NEW** | No ramp-up periods | Per-user ramp config, adjusted benchmarks, advisory notices |
| 16 | Retrospective & Action Items | **NEW** | No action item tracking | Action items from monthly reports, carry-forward |
| 17 | OOO Parsing | **NEW** | No OOO channel monitoring | NLP parsing of `#out-of-office`, date extraction |
| 18 | Task Sizing (S/M/L + weights) | **PARTIAL** | Tasks have priority (1-5) but no size/weight | Add size, weight, task-type columns |
| 19 | KPIs by Role | **NEW** | No role-based benchmarks | KPI targets per role, weekly comparison engine |
| 20 | Slash Commands | **PARTIAL** | /hitler exists | Add /blocked, /unblocked, /log-intervention, /red-card, /dismiss-card, /ooo |
| 21 | Checklists/SOPs (Manager thoughts) | **NEW** | No checklist system | Predefined checklists per role, completion tracking |
***
## Database Changes Required
### New Tables
```
clients
id, organizationId, name, deploySch (day of week)
contentCadence (newsletters/week), status
assignedWriters[], assignedDesigners[]
createdAt, updatedAt
cards
id, userId, organizationId, type (yellow/red)
reason, triggeredBy (auto/manual), relatedTaskId
issuedAt, weekNumber, yearNumber
dismissed (boolean), dismissedBy, dismissReason
autoGenerated (boolean)
interventions
id, loggedBy, attributedTo, organizationId
description, createdAt
includedInReports[]
morning_threads
id, organizationId, slackChannelId, slackThreadTs
date, status (open/closed)
createdAt
thread_submissions
id, morningThreadId, userId
slackMessageTs, rawText
submittedAt, isLate (boolean)
task_statuses (end-of-day)
id, taskId, userId, date
status (done/carry_forward/dropped/no_update)
carryForwardReason, carryForwardCount
updatedAt
blockers
id, taskId, userId, organizationId
description, blockedBy (userId, nullable)
reportedAt, resolvedAt, resolution
escalatedToFounderAt
ooo_records
id, userId, organizationId
startDate, endDate, reason
parsedFromMessage, slackMessageTs
approved (boolean)
action_items
id, organizationId, sourceReportId
text, assignedTo, status (open/in_progress/done/deferred)
carriedForwardCount, createdAt, updatedAt
reports
id, organizationId
type (daily_public/daily_private/weekly_public/weekly_private/monthly)
generatedAt, postedToChannel, slackMessageTs
content (JSON), actionItems[]
kpi_targets
id, organizationId, role, kpiName
target, unit, notes
createdAt, updatedAt
task_type_map
id, organizationId
taskType, keywords[], size (S/M/L)
weight, notes
createdAt, updatedAt
checklists
id, organizationId, name, role
items (JSON array), isActive
createdAt, updatedAt
checklist_completions
id, checklistId, userId, date
completedItems (JSON), completedAt
```
### Modified Tables
```
tasks (add columns)
+ taskType (varchar) — "newsletter_draft", "social_post", etc.
+ size (enum: S/M/L)
+ weight (integer: 1/3/5)
+ clientId (FK to clients)
+ carryForwardCount (integer, default 0)
+ isAiAssisted (boolean)
+ opsOverrideType, opsOverrideSize, opsOverrideClient
task_drafts (add columns)
+ taskType, size, weight, clientId
+ isAiAssisted
users (add columns)
+ rampUpStartDate (date, nullable)
+ rampUpDurationWeeks (integer, default 4)
+ assignedClients[] (relation)
```
***
## New API Modules Required
| Module | Purpose | Key Endpoints/Services |
| ----------------- | ----------------------------- | -------------------------------------------------------------------- |
| `cards` | Yellow/red card management | Issue, dismiss, list, weekly reset, auto-convert (3 yellow to 1 red) |
| `clients` | Client CRUD + health tracking | Create, list, update, assign members, deploy schedules |
| `morning-threads` | Thread lifecycle management | Create thread, track submissions, scan replies |
| `reports` | Scheduled report generation | Daily/weekly/monthly, public/private, archive |
| `kpi` | KPI engine | Role targets, weekly comparison, underperformer detection |
| `interventions` | Invisible labor logging | Log, list, attribute, include in reports |
| `blockers` | Blocker tracking + escalation | Report, resolve, escalation timeline |
| `ooo` | Out-of-office management | Parse messages, store records, exempt from cards |
| `action-items` | Retrospective action tracking | Create from reports, carry forward, mark done |
| `checklists` | SOP/checklist management | Define per role, track completion |
| `classification` | Auto-classification engine | Task-type keyword map, auto-tag, ops review |
| `reinforcement` | Positive reinforcement | Daily shoutout, performer of week, employee of month |
***
## New Cron Jobs Required
| Time | Job | Module |
| ------------------------- | ------------------------------------------------------- | ----------------------- |
| 9:00 AM | Post morning thread in `#today-in-progress` | morning-threads |
| 11:00 AM | Scan thread for missing submissions, issue yellow cards | cards + morning-threads |
| 11:30 AM | Send auto-classification digest to ops | classification |
| 5:00 PM | Post status nudge in morning thread | morning-threads |
| 7:00 PM | Collect end-of-day statuses, process carry-forwards | morning-threads + tasks |
| 9:00 PM | Generate + post daily reports (public + private) | reports |
| Thursday 6:00 PM | Send Thursday check-in DMs to underperformers | kpi |
| Friday 6:00 PM | Generate + post weekly reports (public + private) | reports |
| Last working day, 6:00 PM | Generate + post monthly report (private) | reports |
| Monday 12:00 AM | Reset weekly yellow card counts | cards |
All crons must be timezone-aware and use the existing `DynamicCronService` pattern.
***
## New Slash Commands
| Command | Handler | Purpose |
| ------------------------------------------ | -------------------- | --------------------------------------------------- |
| `/blocked [task] [reason]` | blockers module | Report a blocker, notify ops |
| `/unblocked [task]` | blockers module | Mark blocker resolved |
| `/log-intervention @person [description]` | interventions module | Log invisible labor |
| `/red-card @person [reason]` | cards module | Manually issue red card |
| `/dismiss-card @person [card-id] [reason]` | cards module | Dismiss a card |
| `/ooo [start] [end] [reason]` | ooo module | Structured OOO (optional, bot also parses freeform) |
***
## Implementation Phases
### Phase 1: Foundation (Data Model + Core Loop)
**Goal:** Morning thread to task submission to end-of-day collection to basic daily report.
**Workstreams (parallelizable via worktrees):**
**Branch:** `feat/v2-schema` — **Merged**
* ✅ Added new tables: `clients`, `cards`, `morning_threads`, `thread_submissions`, `task_statuses`, `ooo_records`, `task_type_map`
* ✅ Modified `tasks` table: added `taskType`, `size`, `weight`, `clientId`, `carryForwardCount`
* ✅ Modified `task_drafts` table: added same columns
* ✅ Modified `users` table: added `rampUpStartDate`, `rampUpDurationWeeks`
* ✅ Generated migration
* ✅ Added enums: TaskSize, TaskType, CardType, CardTrigger, ReportType, TaskStatusType, OOOStatus
**Branch:** `feat/v2-clients` — **Merged**
* ✅ New `clients` module in API (CRUD + assign members + deploy schedules)
* ✅ Client-task relationship
* ✅ Admin dashboard page for client config
* ✅ SDK methods for client operations
* ✅ `apps/api/src/modules/clients/` — service, controller, module
* ✅ `apps/web/src/app/dashboard/clients/` — admin UI
**Branch:** `feat/v2-morning-threads` — **Merged**
* ✅ New `morning-threads` module with service, controller, and REST endpoints
* ✅ Cron: `{orgId}:morning-thread` posts daily thread at configured time (default 9 AM)
* ✅ Cron: `{orgId}:submission-deadline` checks missing submissions at configured time (default 11 AM), DMs users who haven't replied
* ✅ Track thread TS per day per org in `morning_threads` table
* ✅ Slack bot detects replies to morning threads, records as `thread_submissions`
* ✅ SDK methods: `getTodayMorningThread`, `recordThreadSubmission`, `findMorningThreadByTs`
* ✅ Org preferences: `enableMorningThread`, `morningThreadTime`, `submissionDeadlineTime`
**Branch:** `feat/v2-eod-collection` — **Merged**
* ✅ 5 PM nudge posted as reply to morning thread
* ✅ 7 PM scan: parse emoji statuses, detect done/carry-forward/dropped
* ✅ Carry-forward counter incremented on tasks
* ✅ No-update detection for users who don't reply
* ✅ Store in `task_statuses` table
* ✅ Daily summary posted to progress channel
* ✅ New org preferences: `eodNudgeTime`, `eodCollectionTime`
***
### Phase 2: Accountability Layer
**Goal:** Card system + auto-classification + ops review + blocker tracking.
**Branch:** `feat/v2-cards` — **COMPLETED**
* New `cards` module (issue, dismiss, list, auto-convert)
* Yellow card triggers: missing submission (11 AM), task overdue 2+ days, no EOD update
* Red card: 3 yellows/week auto-converts, manual via /red-card
* Weekly reset (ISO week tracking)
* DM notification on card issuance
* Card exemptions: OOO, ramp-up period (first 2 weeks grace)
**Files created:**
* `apps/api/src/modules/cards/` — service, controller, module
* `packages/rules/src/cards.ts` — pure evaluation functions
* `tests/unit/card-rules.test.ts` — 23 tests
**Branch:** `feat/v2-classification` — **COMPLETED**
* Task-type-to-size keyword map (admin-configurable)
* On task submission: match against keywords, auto-assign type/size/weight/client
* Confidence scoring — if uncertain, default to "Ad-hoc / M"
* 11:30 AM classification digest posted to ops channel
* Admin UI for task-type map management
**Files created:**
* `apps/api/src/modules/classification/` — service, controller, module
* `apps/web/src/app/dashboard/settings/task-types/page.tsx` — admin UI
* `tests/unit/classification.test.ts` — unit tests
* SDK methods: `classifyTask`, `getTaskTypeMap`, `createTaskTypeMapEntry`, etc.
**Branch:** `feat/v2-blockers` — **COMPLETED**
* ✅ `/blocked` and `/unblocked` slash commands
* ✅ Auto-detection from carry-forward reasons mentioning dependencies
* ✅ Escalation: 0h ops notified, 8h founder DM, 24h critical in report
* ✅ Resolution time tracking
**Files created:**
* `apps/api/src/modules/blockers/` — service, controller, module
* `packages/db/src/schema/blockers.ts` — blocker table
* Slash command handlers in adapters (parser + conversation)
**Branch:** `feat/v2-ooo` — **COMPLETED**
* ✅ Monitor `#out-of-office` channel in real-time
* ✅ NLP extraction: person, date range, reason
* ✅ Store in `ooo_records`
* ✅ Used by card system for exemptions
* ✅ Used by KPI engine for prorated targets
* ✅ Fallback: `/ooo` structured command
**Files created:**
* `apps/api/src/modules/ooo/` — service, controller, module
* LLM-based date/person extraction
* SDK methods for OOO operations
* Daily status transition cron
***
### Phase 3: Intelligence Layer
**Goal:** KPI engine + Thursday check-ins + weekly reports + client health.
**Branch:** `feat/v2-kpi` — **Merged**
* ✅ Per-role KPI targets (full CRUD API + seed defaults)
* ✅ Weekly comparison: actual output vs target with composite scoring
* ✅ Onboarding ramp-up prorating (configurable duration, graduated multiplier)
* ✅ OOO prorating (targets reduced proportionally to days absent)
* ✅ Workload distribution calculation (weighted task points)
* ✅ KPI trends (4-week history per user)
* ✅ Weekly snapshot cron: `{orgId}:weekly-kpi-snapshot` (Friday 11 PM)
* ✅ Performance levels: exceptional / strong / on\_track / below / critical
* ✅ Admin UI for KPI target management (settings page)
**Implemented:**
* `apps/api/src/modules/kpi/` — service, controller, module
* DB tables: `kpi_targets`, `kpi_snapshots`
* SDK methods: `getKpiTargets()`, `setKpiTarget()`, `getWeeklyKpi()`, `getTeamKpi()`, etc.
* Web admin UI: `apps/web/src/app/dashboard/settings/kpi-targets/page.tsx` — full CRUD, seed defaults, team KPI summary, grouped by role
**Branch:** `feat/v2-reports` — **COMPLETED**
* **Daily Public (9 PM):** Per-person task list + completion % (weighted), team total
* **Daily Private (9 PM):** Public + cards issued, stale tasks, OOO context, intervention logs, client summary
* **Weekly Public (Fri 6 PM):** Team stats, target day compliance, performer of week
* **Weekly Private (Fri 6 PM):** Individual KPI comparison, card tally, carry-forward patterns, client health, workload distribution, recommended actions
* **Monthly (Last working day):** Trend lines, card history, recurring blockers, scalability assessment, employee of month, recommended 1:1s, action items
**Implemented:**
* `apps/api/src/modules/reports/` — service, controller, report templates
* Intervention logging (`/log-intervention` command)
* Action items with carry-forward tracking
* Auto-generated recommended actions based on team data
* New DB tables: `reports`, `interventions`, `action_items`
* SDK methods: `getReports()`, `logIntervention()`, `getActionItems()`, etc.
* Dynamic crons: `daily-report` (9 PM), `weekly-report` (Fri 6 PM), `monthly-report` (last working day 6 PM)
**Branch:** Built into `feat/v2-kpi` — **Merged**
* ✅ Calculate week-to-date performance per person vs KPI targets
* ✅ Check OOO records for absences (skip OOO users)
* ✅ If below critical threshold AND not OOO, send empathetic DM
* ✅ Red card context: different message if red card issued this week
* ✅ Dynamic cron: `{orgId}:thursday-checkin` (Thursday 6 PM)
* ✅ Manual trigger endpoint: `POST /kpi/thursday-checkin`
**Implemented in:** `apps/api/src/modules/kpi/kpi.service.ts` → `runThursdayCheckIn()`
**Branch:** `feat/v2-client-health`
* ✅ `ClientHealthService` with per-client task rollup, deploy compliance, health score (0-100)
* ✅ Health levels: healthy (≥75), at\_risk (≥50), critical (\<50)
* ✅ Deploy streak counting and week-over-week completion trend
* ✅ Per-member breakdown (writers/designers) and 4-week weekly trend
* ✅ API endpoints: `GET /clients/health`, `GET /clients/:id/health`
* ✅ SDK methods: `getClientHealth()`, `getClientHealthDetail()`
* ✅ Dashboard rewritten with real health data (score, completion, streaks, member breakdown)
* ✅ Client health section wired into weekly private and monthly reports
* ✅ Unit tests for health score calculation, thresholds, deploy streaks
**Depends on:** 1B (client management), 3B (reports)
***
### Phase 4: Reporting Dashboard + Polish
**Goal:** Admin dashboard, positive reinforcement, retrospectives.
**Branch:** `feat/v2-remaining-gaps` — **COMPLETED**
* ✅ `log_intervention` LLM tool in ChatService — resolves user by name, logs via InterventionsService
* ✅ Posts to progress channel automatically
* ✅ Already surfaced in private daily/weekly/monthly reports (existing ReportsService integration)
**Branch:** `feat/v2-reinforcement` — **COMPLETED**
* ✅ **Daily:** 100% completion triggers public shoutout in #wins channel
* ✅ **Weekly:** Performer of the Week (highest weighted completion)
* ✅ **Monthly:** Employee of the Month auto-nomination
* ✅ Post in configurable `#wins` channel (falls back to progress channel)
* ✅ DM recognized users
* ✅ Reinforcement history tracking with REST API
* ✅ Admin settings UI (toggle + channel picker)
* ✅ SDK methods: `getReinforcementHistory()`, `triggerDailyShoutout()`, `triggerWeeklyPerformer()`
* ✅ Unit tests for selection logic
**Files created:**
* `apps/api/src/modules/reinforcement/` — service, controller, module
* `packages/db/src/schema/reinforcements.ts` — DB schema
* `tests/unit/reinforcement.test.ts` — unit tests
✅ **COMPLETED** — Action Items admin UI with auto-creation from reports
* ✅ Action items admin dashboard page with filters (status, priority, assignee)
* ✅ Inline status updates (mark done, cancel)
* ✅ Create new action items manually
* ✅ Auto-creation of action items from weekly report recommendations
* ✅ Duplicate detection prevents re-creating existing open items
* ✅ Carry-forward badge display
* ✅ "View all" link from Reports page to Action Items
* ✅ Count endpoint for nav badge
**Branch:** `feat/dashboard-overhaul`
✅ **COMPLETED** — Ops-brain command center dashboard
* ✅ **Today view:** Live task feed grouped by person, completion %, card pills, cron status, alerts
* ✅ **Clients view:** Health dashboard with metrics, deploy streaks, sparklines
* ✅ **Team view:** Per-person KPI, card history, task list with advisory notes
* ✅ **Reports view:** Weekly Private/Public, Daily Digest tabs
* ✅ **Cards view:** Card log, dismiss, manual red card issuance, rules reference
* ✅ **Dark theme:** IBM Plex Mono + Instrument Serif, custom ops-brain color palette
* ✅ **Employee view:** Simplified dashboard retained for non-manager roles
***
### Phase 5: Checklists & SOPs (from Manager Thoughts)
**Goal:** Pre-defined checklists and SOPs for process enforcement.
This phase addresses the manager's additional requirements that are NOT in the PRD but were
provided as supplementary input. These should be validated with the manager before implementation.
**Branch:** `feat/v2-checklists`
New module for pre-defined checklists that team members complete:
**Content Writing Checklist:**
* Correct hyperlinks
* AI-slop edited out
* Appropriate writing style
* Poll/news/tools/NL outline correctly followed
**Content QC Checklist (before design handoff):**
* No AI-slop present
* Topic makes sense
* Writing style appropriate
**Design QC Checklist:**
* Redirect URL added to polls
* Hyperlinks correct
* Images/media clickable
**Client QC Checklist:**
* Subject line options shared
* Scheduled/followed up on time
**Designer Checklist:**
* All thumbnails updated twice a week
* New briefs delivered on time
* Turnaround time for all clients under 24 hrs
* 1 new design task independently picked and executed every week
**Files to create:**
* `apps/api/src/modules/checklists/` — service, controller
* DB tables: `checklists`, `checklist_completions`
* Admin UI for checklist management
* Bot integration: checklist completion via Slack
**Branch:** `feat/v2-sops` — **COMPLETED**
Automated tracking of recurring SOPs:
**Client SOP:**
* Weekly report on Monday
* Monthly report on last day of month
* Monthly call scheduled with each client
**Internal Ops:**
* Deadlines adhered
* `#ooo` process followed
* Discussions in public channels
* Monthly 1:1 with ops/manager
**Analytics SOP:**
* Reports updated every Monday
* Shared with respective clients after internal QC
* Internal sync (analytics call) for data-driven decisions
**Client Onboarding:**
* Onboarding form filed
* Added to Slack (primary) / WhatsApp (secondary)
* Weekly reports on experiments during month 1
* Month 1 performance report
* Swift onboarding to remaining SOPs
**Employee Onboarding:**
* Go through master client database
* Read checklist of processes (internal ops checklist)
* Read 5+ newsletter editions (or 10 social posts) of assigned clients
* Create 1-pager on client understanding
* Daily 1:1 with ops during week 1
* Weekly 1:1 during month 1
* Then regular monthly cadence
***
## PRD Open Questions (Need Answers Before Implementation)
These are flagged in the PRD as unresolved. **Must be answered before starting Phase 3:**
| # | Question | Impact | Suggested Default |
| - | ----------------------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------------- |
| 1 | **Newsletter quality metrics (open rate, CTR) — data source?** | KPI engine needs this for writer evaluation | Start without it; add Beehiiv API integration later |
| 2 | **Designer dependency tracking — how to detect content handoff?** | Affects designer KPI calculation and blocker detection | ✅ Resolved: auto-notifies designers when content tasks complete |
| 3 | **AI-assisted vs manual drafts — how does bot know?** | Changes task weight (M vs L for newsletter drafts) | Default to AI-assisted (M); writer or ops can override to manual (L) |
| 4 | **Multiple tasks in one message — one per line or list?** | Parser needs to handle both formats | Support both: numbered list and one-per-line |
| 5 | **Weekend work — does bot run Saturday/Sunday?** | Cron schedule, card exemptions | ✅ Resolved: Mon-Fri only via `isWorkingDay()` + holiday config |
| 6 | **Engagement metrics for socials/community — definition?** | Social writer KPI | Defer until baseline established; track volume only initially |
***
## Items Missing from PRD (Identified During Analysis)
Things the current codebase has that the PRD doesn't address, or gaps in the PRD itself:
| # | Gap | Recommendation |
| -- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| 1 | **Multi-tenancy** — PRD is single-org focused but codebase is multi-tenant | Keep multi-tenant architecture; configure Inagiffy as the primary org |
| 2 | **Existing mood system** — PRD replaces daily mood with Thursday check-in only | Keep daily mood as optional; Thursday check-in is the mandated one |
| 3 | **Existing flags system** — PRD introduces cards which are different from flags | Run both: flags for wellbeing patterns, cards for accountability |
| 4 | **Existing reminders** — PRD doesn't mention personal reminders | Keep reminders; they complement the accountability system |
| 5 | **Web dashboard chat** — PRD is entirely Slack-focused | Keep web chat for admin convenience |
| 6 | **Journal feature** — PRD's Thursday check-in is similar but different | Keep journals as private; Thursday check-in is separate (shared with leadership) |
| 7 | **Inquiry system** — PRD has no equivalent | Keep for HR/support threads |
| 8 | **Checklist system** — Manager wants it but PRD doesn't include it | Add as Phase 5 (separate from PRD scope) |
| 9 | **Analytics SOP automation** — Manager wants automated Monday reports to clients | Needs external integration (Beehiiv, social analytics APIs) — defer |
| 10 | **Public holiday config** — PRD mentions it but no detail | ✅ Done: `holidays` array in org preferences + `isWorkingDay()` utility |
| 11 | **"Same as yesterday" detection** — PRD mentions flagging low-effort submissions | ✅ Done: Jaccard similarity >85% flags to ops channel |
| 12 | **Task reassignment** — PRD mentions "consider reassigning" for stale tasks but no mechanism | ✅ Done: `reassign_task` LLM tool + `TasksService.reassignTask()` |
***
## Effort Estimates by Phase
| Phase | Scope | Parallel Worktrees | Key Risk |
| ----------- | ------------------ | ------------------- | ------------------------------------------------ |
| **Phase 1** | Foundation | 4 worktrees (1A-1D) | Schema migration on production DB |
| **Phase 2** | Accountability | 4 worktrees (2A-2D) | Card system edge cases (OOO, ramp-up exemptions) |
| **Phase 3** | Intelligence | 4 worktrees (3A-3D) | KPI calibration, report template design |
| **Phase 4** | Dashboard + Polish | 4 worktrees (4A-4D) | Admin UI scope creep |
| **Phase 5** | Checklists/SOPs | 2 worktrees (5A-5B) | Needs manager validation before starting |
***
## Worktree Strategy for Parallel Development
Each phase has independent workstreams that can be developed in parallel using `wt create`:
```bash theme={null}
# Phase 1 — all can run in parallel
wt create feat/v2-schema # Agent 1: Database changes
wt create feat/v2-clients # Agent 2: Client management
wt create feat/v2-morning-threads # Agent 3: Thread system
wt create feat/v2-eod-collection # Agent 4: EOD collection (starts after schema merges)
```
Merge order: Schema first, then clients + morning-threads (parallel), then EOD collection last (depends on both).
***
## Files That Will Be Modified (Existing)
These existing files will need changes (not just new files):
| File | Change |
| --------------------------------------------------- | --------------------------------------------------------------------------- |
| `packages/db/src/schema/tasks.ts` | Add taskType, size, weight, clientId columns |
| `packages/db/src/schema/users.ts` | Add rampUp fields |
| `packages/db/src/schema/index.ts` | Export new schemas |
| `packages/shared/src/enums.ts` | New enums: TaskSize, CardType, TaskType, ReportType |
| `apps/api/src/modules/chat/chat.service.ts` | New LLM tools for classification, clients |
| `apps/api/src/modules/jobs/dynamic-cron.service.ts` | Register new per-org crons (morning thread, EOD, reports) |
| `apps/api/src/modules/jobs/scheduler.service.ts` | New static crons (card reset, monthly report) |
| `apps/bot-slack/` | New slash command handlers, interactive message handlers, thread management |
| `packages/sdk/` | New client methods for all new modules |
| `packages/adapters/src/parser.ts` | Handle new slash commands |
| `packages/rules/src/` | Card evaluation rules, KPI rules |
| `apps/web/src/app/dashboard/` | New admin pages (clients, cards, reports, KPIs, checklists) |
| `docs/mint.json` | Add new doc pages to navigation |
***
## Migration Strategy
The database schema changes are significant. Plan a migration window.
1. **All new tables are additive** — no existing tables are dropped
2. **Existing column additions** are nullable or have defaults — no data loss
3. **Run migrations on staging first**, verify with seed data
4. **Backfill strategy**: Existing tasks won't have type/size/client — mark as "unclassified" and let ops tag retroactively (or ignore historical data)
5. **Feature flags**: New crons should be gated behind org preferences (e.g., `enableMorningThread`, `enableCardSystem`) so they can be turned on gradually
***
## Cross-Cutting: Multi-Agent Bot Architecture
This section addresses the multi-agent bot architecture discussed in the ops meeting. The manager
wants multiple specialized bots to automate ops enforcement — removing manual follow-ups and
reducing personality conflicts in accountability. **Status: Proposal — pending manager approval.**
### Problem
Today, ops manually does all follow-ups: chasing late submissions, reminding about deadlines, escalating unresolved blockers, and checking on client health. This is tedious and creates personality conflicts ("the Hitler aspect of ops work"). A single general-purpose bot cannot handle all of these proactively — it only responds when spoken to.
### Proposed Architecture: 3 Specialized Agents
Instead of one bot that does everything, we split Hitler into **3 autonomous agents** that each own a specific domain and act proactively on schedules and triggers. They share the same Slack workspace, database, and API — but each has its own personality, schedule, and escalation rules.
```
┌──────────────────────────────────────────────────────────┐
│ Hitler (Slack Bot) │
│ │
│ ┌────────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Follow-Up Agent│ │ Task Agent │ │ Escalation │ │
│ │ │ │ │ │ Agent │ │
│ │ Deadlines, │ │ Morning │ │ Blockers, │ │
│ │ reminders, │ │ threads, │ │ stale tasks, │ │
│ │ nudges, │ │ classification│ │ client health│ │
│ │ check-ins │ │ EOD status │ │ red flags │ │
│ └───────┬────────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ ▼ │
│ Shared Services │
│ (DB, Redis, BullMQ, Slack API) │
└──────────────────────────────────────────────────────────┘
```
### Agent Breakdown
#### 1. Follow-Up Agent (Automates manual chasing)
The biggest ops time sink. This agent proactively DMs people and posts reminders so ops never has to manually follow up.
| Trigger | Action |
| --------------------------------------- | ----------------------------------------------------------------------- |
| 11 AM, no morning submission | DM: "Hey, you haven't posted in today's thread yet. Need help?" |
| Task approaching deadline (same day) | DM: "Heads up — \[task] for \[client] is due today." |
| Carry-forward day 2 | DM: "This task has been carried forward 2 days. What's the blocker?" |
| Thursday, below 60% weekly KPI | Empathetic check-in DM (existing Thursday check-in logic) |
| Post-deadline, no status update by 6 PM | DM: "How did \[task] go today? Done / carrying forward / blocked?" |
| Best practice violation detected | DM: "Reminder: \[client] posts need redirect URLs. Missing on today's." |
**Key design:** Messages come from the bot, not from ops. This removes the personality conflict — the bot is enforcing process, not a person.
#### 2. Task Agent (Manages the daily task lifecycle)
Owns the morning-to-evening task flow. This is the "living functional agentic brain" for daily operations.
| Trigger | Action |
| ----------------------------- | ------------------------------------------------------------------------ |
| 9 AM daily | Post morning thread in channel |
| Team member replies in thread | Parse tasks, auto-classify type/size/client, create task drafts |
| 11:30 AM | Send classification digest to ops (confirm/override via Slack buttons) |
| "Same as yesterday" detected | Flag to ops: "Lazy update from \[Name] — identical to yesterday's tasks" |
| 7 PM daily | Collect EOD statuses, process carry-forwards, update task records |
| 9 PM daily | Generate and post daily reports (public + private) |
| Context-aware prioritization | Tag tasks by client urgency based on deploy schedules |
**"Same as yesterday" detection:** The classification engine compares today's submission against the previous day's. If similarity is above 85%, it flags to ops rather than auto-accepting.
#### 3. Escalation Agent (Catches things falling through cracks)
Monitors for problems that need attention and escalates with increasing urgency. Replaces the manual "checking in on everything" that ops does.
| Trigger | Action |
| ----------------------------------------------- | ----------------------------------------------------------- |
| Blocker unresolved for 8 hours | DM to founder/manager with context |
| Blocker unresolved for 24 hours | Flag as critical in daily report, suggest reassignment |
| Client deploy day approaching, tasks incomplete | Alert ops: "\[Client] deploys Thursday, 3 tasks still open" |
| 3 yellow flags in a week | Auto-escalate to red flag, notify ops |
| Task stale for 5+ days | Flag as "dead task" in report, suggest drop or reassign |
| New client in first month, KPIs lagging | Advisory notice (not penalty) — onboarding ramp-up |
### How It Maps to Our Existing Architecture
The multi-agent system does **not** require a rewrite. It builds on what we already have:
| What We Have | What It Becomes |
| ----------------------------- | ------------------------------------------------------------------- |
| Single `ChatService` | Split into 3 agent services, each with focused LLM system prompt |
| `DynamicCronService` | Registers crons for all 3 agents (already supports per-org crons) |
| BullMQ job queues | Each agent gets its own queue + a shared `agent-events` queue |
| Slack bot (single responder) | Still one Slack app — agents share it, post under the same bot name |
| `packages/rules/` | Escalation rules, flag evaluation, "same as yesterday" detection |
| `packages/adapters/parser.ts` | Routes user messages to the correct agent based on intent |
**Single Slack app, multiple brains.** The team sees one bot ("Hitler") but behind the scenes, different agents handle different message types. No need for multiple Slack app installs.
### Inter-Agent Communication
Agents don't call each other directly. They communicate through **events on BullMQ**:
| Event | From | To | Example |
| ----------------------- | ---------------- | ---------------- | ------------------------------------------------ |
| `task.carry_forward` | Task Agent | Follow-Up Agent | Trigger day-2 carry-forward DM |
| `task.carry_forward` | Task Agent | Escalation Agent | Day 3+ triggers flag evaluation |
| `task.completed` | Task Agent | Escalation Agent | Clear any pending escalation for that task |
| `flag.issued` | Escalation Agent | Task Agent | Annotate task with flag reference |
| `submission.missing` | Task Agent | Follow-Up Agent | 11 AM missing submission triggers DM |
| `blocker.reported` | Task Agent | Escalation Agent | Start escalation timer (8h, 24h) |
| `deadline.approaching` | Task Agent | Follow-Up Agent | Send deadline reminder DM |
| `client.deploy_at_risk` | Escalation Agent | Follow-Up Agent | Nudge assigned team members about at-risk deploy |
### Implementation Plan
This is **not a separate phase** — the agent split happens incrementally alongside the existing phases:
**During Phase 1-2 (now):** Build all features in the single ChatService as planned. But design services with clean interfaces so they can be extracted later. Specifically:
* Keep follow-up logic in its own service class (not mixed into cron handlers)
* Keep escalation rules in `packages/rules/` (already planned)
* Use BullMQ events between modules (not direct service calls)
**During Phase 3 (KPI + reports):** Extract the 3 agents as separate NestJS service classes within the API app. Each gets:
* Its own system prompt (focused, under 2K tokens each instead of one 6K+ prompt)
* Its own tool set (8-10 tools each instead of 25+ in one service)
* Its own BullMQ worker for processing events
**What this looks like in code:**
```
apps/api/src/modules/agents/
follow-up.agent.ts # Follow-Up Agent service
task.agent.ts # Task Agent service
escalation.agent.ts # Escalation Agent service
agent-router.service.ts # Routes user messages to correct agent
agent-events.processor.ts # Processes inter-agent BullMQ events
```
**Key constraint:** All 3 agents live in the **same NestJS app, same deployment, same database**. No microservices complexity. Just clean separation of concerns with focused LLM prompts.
### Cost and Model Considerations
Splitting into agents also enables **cost optimization**:
* **Follow-Up Agent:** Can use a cheaper, faster model (e.g., Haiku) — it sends templated messages with light personalization
* **Task Agent:** Needs the strongest model (Sonnet/Opus) for accurate classification and natural language parsing
* **Escalation Agent:** Medium model (Sonnet) — rule-based triggers with LLM for writing escalation summaries
At Inagiffy's scale (10 users, \~50-100 messages/day), the total LLM cost stays low regardless. But the split means each agent's context window is smaller and more focused, which improves accuracy.
***
## Definition of Done (per Phase)
* All new API endpoints have Zod validation
* All new crons are timezone-aware and respect org preferences
* All Slack messages use proper Block Kit formatting
* All new features have unit tests (Vitest)
* SDK is updated with typed methods for all new endpoints
* Docs are updated for new features
* No existing tests are broken
* No existing features are degraded