Pivot Roadmap: Accountability Bot

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):

1A: Database Schema Changes ✅ COMPLETED

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

1B: Client Management Module ✅ COMPLETED

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

1C: Morning Thread System ✅ COMPLETED

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

1D: End-of-Day Collection ✅ COMPLETED

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.

2A: Card System ✅

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

2B: Auto-Classification Engine ✅

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.

2C: Blocker System ✅

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)

2D: OOO Parsing ✅

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.

3A: KPI Engine ✅ COMPLETED

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

3B: Report Generation ✅

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)

3C: Thursday Check-In ✅ COMPLETED

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()

3D: Client Health Tracking ✅ COMPLETED

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.

4A: Invisible Labor Logging ✅

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)

4B: Positive Reinforcement ✅

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

4C: Action Item Tracking

✅ 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

4D: Admin Dashboard Updates

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.

5A: Checklist System ✅ COMPLETED

Branch: feat/v2-checklistsNew 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

5B: SOP Tracking ✅

Branch: feat/v2-sops — COMPLETEDAutomated 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:

# 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.

All new tables are additive — no existing tables are dropped
Existing column additions are nullable or have defaults — no data loss
Run migrations on staging first, verify with seed data
Backfill strategy: Existing tasks won’t have type/size/client — mark as “unclassified” and let ops tag retroactively (or ignore historical data)
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

​Executive Summary

​What Changes

​What Stays

​Gap Analysis: PRD vs Current Codebase

​Legend

​Feature-by-Feature Breakdown

​Database Changes Required

​New Tables

​Modified Tables

​New API Modules Required

​New Cron Jobs Required

​New Slash Commands

​Implementation Phases

​Phase 1: Foundation (Data Model + Core Loop)

​Phase 2: Accountability Layer

​Phase 3: Intelligence Layer

​Phase 4: Reporting Dashboard + Polish

​Phase 5: Checklists & SOPs (from Manager Thoughts)

​PRD Open Questions (Need Answers Before Implementation)

​Items Missing from PRD (Identified During Analysis)

​Effort Estimates by Phase

​Worktree Strategy for Parallel Development

​Files That Will Be Modified (Existing)

​Migration Strategy

​Cross-Cutting: Multi-Agent Bot Architecture

​Problem

​Proposed Architecture: 3 Specialized Agents

​Agent Breakdown

​1. Follow-Up Agent (Automates manual chasing)

​2. Task Agent (Manages the daily task lifecycle)

​3. Escalation Agent (Catches things falling through cracks)

​How It Maps to Our Existing Architecture

​Inter-Agent Communication

​Implementation Plan

​Cost and Model Considerations

​Definition of Done (per Phase)

Executive Summary

What Changes

What Stays

Gap Analysis: PRD vs Current Codebase

Legend

Feature-by-Feature Breakdown

Database Changes Required

New Tables

Modified Tables

New API Modules Required

New Cron Jobs Required

New Slash Commands

Implementation Phases

Phase 1: Foundation (Data Model + Core Loop)

Phase 2: Accountability Layer

Phase 3: Intelligence Layer

Phase 4: Reporting Dashboard + Polish

Phase 5: Checklists & SOPs (from Manager Thoughts)

PRD Open Questions (Need Answers Before Implementation)

Items Missing from PRD (Identified During Analysis)

Effort Estimates by Phase

Worktree Strategy for Parallel Development

Files That Will Be Modified (Existing)

Migration Strategy

Cross-Cutting: Multi-Agent Bot Architecture

Problem

Proposed Architecture: 3 Specialized Agents

Agent Breakdown

1. Follow-Up Agent (Automates manual chasing)

2. Task Agent (Manages the daily task lifecycle)

3. Escalation Agent (Catches things falling through cracks)

How It Maps to Our Existing Architecture

Inter-Agent Communication

Implementation Plan

Cost and Model Considerations

Definition of Done (per Phase)