---
All 27 scheduled tasks in C:/Users/Harnoor/.claude/scheduled-tasks/.
| # | Task Name | Schedule | Purpose | Script / Command | Script Exists? |
|---|-----------|----------|---------|-----------------|----------------|
| 1 | titan-daily-feed | 4:33 AM daily | ORACLE pulls AI/cloud intel → staging | /feed skill (ORACLE) | N/A (skill) |
| 2 | titan-nightly-reindex | 3:33 AM daily | Re-embed staging entries for RAG search | curl POST /api/rag/reindex | RAG server at 8765 (bridge must be up) |
| 3 | titan-daily-monologue | Daily (time unspecified) | TITAN journals turns/mood/curiosities | Reads logs, writes journal | N/A (skill) |
| 4 | titan-daily-improve | Daily (time unspecified) | DARWIN proposes 1 skill improvement/day | Reads evals/errors/guardrails, writes staging | N/A (skill) |
| 5 | titan-daily-backup | ~11:23 PM daily | Local E: drive backup with 30-day retention | F:/TITAN/sync-backup.sh | EXISTS (F:/TITAN/sync-backup.sh) |
| 6 | titan-daily-log-rotation | 11:52 PM daily | Rotate logs under 50MB | curl POST /api/admin/rotate-logs | Via bridge at 8765 |
| 7 | titan-daily-pa-email | 5:27 AM daily | Morning briefing email via SES | /daily-email skill + titan_email.py | EXISTS (titan_email.py) |
| 8 | titan-daily-newsletter | Daily (time unspecified) | Package /feed intel into The Agent Stack newsletter | /newsletter skill + titan_email.py | EXISTS (titan_email.py) |
| 9 | titan-agent-utilization-daily | 9:00 AM daily | Sub-agent utilization report | agent_utilization_report.py | EXISTS |
| 10 | nightly-report-writer | 5:00 AM daily | Assemble overnight agent work summary | Reads logs/swarm/watchdog, writes nightly-report-*.md | N/A (skill reads files) |
| 11 | nightly-pmf-d7 | Nightly (time unspecified) | Silent Infinity Day-7 return rate → CloudWatch | titan-innerverse-pmf-d7.py | EXISTS |
| 12 | nightly-prompt-eval | Nightly (time unspecified) | SI prompt regression test vs baseline | eval/run_eval.py in F:/projects/innerverse/backend | NOT in scripts/watchdogs (separate project path) |
| 13 | titan-scan-local-md-nightly | Nightly (time unspecified) | Walk drives for .md files, build index | scan_local_md.py | EXISTS |
| 14 | titan-s3-backup-nightly | 2:30 AM daily | Disaster recovery to S3 | titan_s3_backup.py | EXISTS |
| 15 | titan-weekly-dream | Weekly | Memory consolidation cycle (VAULT) | /dream skill | N/A (skill) |
| 16 | titan-weekly-review | Sunday 8 PM | 7-domain life scorecard email | /weekly-review skill + Gmail MCP | N/A (skill) |
| 17 | titan-weekly-benchmark | Sunday 6:17 AM | TITAN health index 0-100 | /benchmark skill | N/A (skill) |
| 18 | titan-monthly-evolve | Monthly | DARWIN pattern mining → proposed skills | /evolve skill | N/A (skill) |
| 19 | claude-code-audit-every-6h | Every 6h (17 min past) | SCOUT audits CC architecture vs SI+TITAN | Dispatches SCOUT agent | N/A (orchestrates agent) |
| 20 | agentic-247-watchdog | Every 30 min | Liveness/security/cost/integrity audit | titan_heartbeat_monitor.py (referenced) | EXISTS (different script; runs inline checks) |
| 21 | swarm-health-orchestrator | Every 15 min | Detect/respawn truncated sub-agents + CloudWatch heartbeat | Inline scan + aws cloudwatch put-metric-data | N/A (skill logic) |
| 22 | titan-heartbeat-monitor-15m | Every 15 min | Out-of-band liveness — SES alert if all sources stale >90min | titan_heartbeat_monitor.py | EXISTS |
| 23 | titan-revive-watch-1m | Every 1 min | Watch for revive-claude.flag, spawn claude.exe if needed | titan_revive_watch.py | EXISTS |
| 24 | titan-bridge-watchdog | Every 5 min | Keep titan_bridge.py running on port 8765 | curl probe → PowerShell Start-Process | Bridge: titan_bridge.py EXISTS |
| 25 | titan-inbox-watch | Every 2 min (was 15m) | Gmail + web-bridge command processor | Gmail MCP + inline file ops | N/A (skill) |
| 26 | silentinfinity-chat-smoke-10m | Every 10 min | Hit SI chat endpoint, alarm on failure | silentinfinity_chat_smoke.py | EXISTS |
| 27 | aws-cost-daily-150-cap | 9:00 AM UTC daily | AWS MTD cost report + SES email | aws_cost_daily.py | EXISTS |
---
agentic-247-watchdog (30m) vs titan-heartbeat-monitor-15m (15m)Both check system liveness. The 247-watchdog is the broad-spectrum checker (process liveness, security, cost surface, state integrity, agent swarm). The heartbeat-monitor is specifically checking if source files have been written to in 90 minutes and escalating via SES/SNS.
Overlap:
The difference: watchdog is broader and more sophisticated; heartbeat-monitor is the pure out-of-band "is ANYTHING happening?" signal. The heartbeat monitor is intentionally the simpler, more reliable fallback.
Verdict: Keep both, but their schedules should be documented as layered by design.
swarm-health-orchestrator (15m) vs agentic-247-watchdog (30m) step 1The watchdog's Process Liveness step explicitly checks swarm-orchestrator.log for a line within 20 minutes. The swarm orchestrator writes to that log every 15 minutes. So the watchdog is checking the swarm orchestrator's own log as a proxy for swarm health.
This is not redundancy — it is a proper observer pattern. The watchdog observes the orchestrator's output rather than re-running the scan. This is correct architecture.
titan-daily-backup (11:23 PM), titan-s3-backup-nightly (2:30 AM)Both back up F:/TITAN. They serve different failure modes:
titan-daily-backup: local E: drive, git commit, fast recovery from accidental deletiontitan-s3-backup-nightly: S3, encrypted, disaster recovery (house fire, drive failure)These are intentionally different and complementary. Do not merge.
However: titan-daily-backup references sync-backup.sh (exists) AND a Python equivalent. The SKILL.md says "execute F:/TITAN/sync-backup.sh (or the Python equivalent)" — ambiguous. The script exists; this is fine, but the SKILL.md should be cleaned to say definitively which one runs.
aws-cost-daily-150-cap (9:00 AM UTC) vs agentic-247-watchdog cost checksThe watchdog reads daily-aws-cost.log (written by the cost script) and llm-costs.jsonl and external-spend.jsonl. It does NOT re-query Cost Explorer. It reads what the cost script wrote.
This is the correct observer pattern: cost script writes fresh data, watchdog reads it. No overlap.
However: a persistent blind spot is exposed. The watchdog log shows 70+ consecutive WARN entries flagging llm-costs.jsonl stale 6d (last written 2026-04-19). This means the watchdog's LLM cost check is permanently broken — it's reading a stale file but the cost script (aws_cost_daily.py) doesn't write llm-costs.jsonl (that's the server's responsibility). This is a gap, not a redundancy, but it matters for the audit picture.
The aws-cost-daily-150-cap email is also broken: daily-aws-cost.log shows email: {'ok': False, 'reason': 'WinError 10061'} from 2026-04-21 onwards — the bridge/SES endpoint was unreachable. However, the script still runs and logs successfully. The SES email delivery failure is persistent.
titan-daily-feed → titan-nightly-reindex → titan-daily-pa-emailThis is a deliberate pipeline:
1. Feed (4:33 AM) populates staging
2. Reindex (3:33 AM) is supposed to run AFTER feed but currently fires BEFORE it
Critical ordering bug: The SKILL.md for titan-nightly-reindex explicitly notes: "feed runs at 4:35 so this should be AFTER feed" and then contradicts itself: "no wait, feed runs at 4:35 so this should be AFTER feed." The schedule description says 3:33 AM but the comment in the SKILL.md says this should run after feed at 4:35 AM. Currently reindex fires at 3:33 AM and feed fires at 4:33 AM — reindex runs 60 minutes BEFORE feed, meaning last night's staging entries are never indexed before the 5:27 AM PA email reads them.
Fix required: Move reindex to 4:53 AM (20 minutes after feed).
nightly-report-writer (5:00 AM) → titan-daily-pa-email (5:27 AM)Intentionally sequential. The PA email reads the nightly report. These must NOT be merged — the report writer produces the data, the PA email delivers it.
titan-daily-newsletter vs titan-daily-pa-email — both read stagingBoth tasks read F:/TITAN/knowledge/staging/ for intelligence content. The newsletter packages it for public consumption; the PA email pulls the top 1-2 insights for Harnoor's personal briefing.
No functional overlap, but both run daily and both risk running a /feed call if staging is empty, which could double-run the feed. The newsletter SKILL.md says "if staging is empty for today, run a quick /feed auto first." If the newsletter fires before feed runs (time not specified), this triggers an unscheduled feed. Recommend: specify newsletter schedule to fire after 5:30 AM so feed has already run.
titan-daily-improve vs titan-monthly-evolve (DARWIN overlap)Both are DARWIN tasks. Improve is micro-cycle (1 proposal/day). Evolve is macro-cycle (monthly pattern mining). They write to different places (improve → staging, evolve → skills-proposed/) and serve different horizons.
No redundancy. These are correctly separated by granularity.
titan-inbox-watch cadence vs signal rateRunning every 2 minutes. Log evidence (mobile-inbox.log) shows that from 2026-04-22T23:40 to 2026-04-23T01:10 — nearly 90 minutes — every poll found 0 new threads. The last real command was processed 2026-04-22. The 2-minute cadence is 7.5x faster than the signal it's polling.
Recommended: revert to 15-minute polling. The SKILL.md itself says the 2-minute cadence was chosen "to make web commands feel close-to-realtime" — but web-bridge commands (source=web) come through the file queue directly and don't require Gmail polling. Only Gmail threads need the 15-minute cadence. The "near-realtime" feeling for web commands could be achieved by having the bridge write to the file queue and letting the 15-minute inbox-watch pick it up, or (better) having titan_bridge.py call the local API directly.
If 2-minute cadence is kept: acceptable for Gmail responsiveness, but note it creates one Claude Code session every 2 minutes continuously = 720 sessions/day. This is the single highest-frequency non-trivial task in the entire system.
titan-revive-watch-1m — fastest task in the systemFires every 1 minute. However, it's a no-op 99.9% of the time (checks for a flag file that only exists when the web /api/revive endpoint is hit). The log confirms: only 1 event in the entire log (2026-04-26T20:40:18Z, REVIVE_NOOP — Claude was already running). This task has fired ~38,400 times since 2026-04-23 and done real work exactly 1 time.
The script itself is instant on a no-op (checks file existence, exits). Cost is minimal. But it is the second-highest frequency task. Recommended: increase to 5 minutes. A revive request that waits 5 minutes instead of 1 minute is still functionally instant from Harnoor's perspective (he won't be staring at the screen for 5 minutes after hitting revive).
---
nightly-prompt-eval — DEGRADED, NOT DEADLog: prompt-eval.log shows:
2026-04-24T04:04:37Z | ERROR | conv=0
2026-04-25T08:05:01Z | ERROR | conv=0
2026-04-26T04:08:40Z | OK | conv=10 | aggregate=7.07
Two consecutive ERROR days (Apr 24-25), then recovered Apr 26. The script path is F:/projects/innerverse/backend/eval/run_eval.py — not in F:/TITAN/scripts/. Script existence was not confirmed via glob (different project root). Not dead, but recently error-prone.
nightly-pmf-d7 — RUNNING BUT RETURNING EMPTY COHORTSLog shows:
2026-04-24: ERROR — DynamoDB scan hung >15min
2026-04-25: cohort_size=0, returned=0, rate=0%
2026-04-26: cohort_size=0, returned=0, rate=0%
The script runs but the DynamoDB table (innerverse-conversations) shows 302 items scanned and 0 users with a first session 7-14 days ago (empty cohort). This is an early-product signal (no 7-day-old users yet), not a script failure. Not dead, just measuring 0 as expected for an early product.
titan-daily-backup — SKIPPED ONE DAYLog shows Apr-22 backup was PARTIAL (git failed, disk full). Apr-23 backup OK. Apr-21 was also PARTIAL. The task exists and runs; the disk-full issue was resolved.
titan-agent-utilization-daily — RUNNING BUT REPORTING 0 RUNSThe daily utilization report for 2026-04-26 shows 0 runs for all 6 agents. This is because F:/TITAN/state/agent-runs.jsonl is not being written to by the named sub-agents (SCOUT, VAULT, etc.) — they're being invoked but not logging their dispatches to that file. The task runs; the input data is missing.
aws-cost-daily-150-cap — RUNNING BUT EMAIL BROKENRuns daily, logs successfully to daily-aws-cost.log (most recent: 2026-04-26 $69.70 MTD, $5.46/day avg, forecast $73.58 rest-of-month — YELLOW at 46% of cap, trending toward RED). SES email has been broken since 2026-04-21 (WinError 10061 — connection refused on the local bridge). Since the bridge watchdog restarts the bridge, this suggests the SES path in aws_cost_daily.py is hitting a different endpoint or the bridge was down at 9:00 AM UTC specifically when this fires. No dead task, but email delivery is broken for 6 days.
---
| Task | Current Freq | Signal Change Rate | Verdict |
|------|-------------|-------------------|---------|
| titan-revive-watch-1m | 1 min | Fired once in 3+ days | Reduce to 5 min — still fast enough |
| titan-inbox-watch | 2 min | 0 real events in 90+ min windows | Revert to 15 min for Gmail polling; web-bridge is file-based (no poll needed) |
| titan-bridge-watchdog | 5 min | Bridge restarts are rare (<daily) | Increase to 10 min — 5 min vs 10 min has no real UX difference; halves session count |
| titan-heartbeat-monitor-15m | 15 min | Liveness changes rarely; persistent WARN states last hours | Acceptable — this is intentionally aggressive for P0 monitoring |
| swarm-health-orchestrator | 15 min | Truncations require fast detection (4+ on a single day historically) | Keep 15 min — the 2026-04-22 truncation storm justifies this |
| agentic-247-watchdog | 30 min | Security surface changes rarely; cost data only refreshes at 9 AM | Increase to 45 min — security scans don't need sub-30min cadence |
| silentinfinity-chat-smoke-10m | 10 min | Catches deploys gone wrong (<11 min SLA per spec) | Keep 10 min — this was specifically set after a multi-hour production outage |
| claude-code-audit-every-6h | 6h | CC releases are weekly; architecture shifts are monthly | Reduce to 12h — 4 audits/day is generating 4+ near-identical memos per day with "n_recs=3 m_regressions=0" consistently. Signal has plateaued. |
---
Tasks that directly incur AWS spend:
| Task | AWS Cost | Notes |
|------|----------|-------|
| silentinfinity-chat-smoke-10m | ~$0.01-0.05/day | CloudWatch PutMetricData + Bedrock (SI invocation) + SES on failure. 144 runs/day. |
| aws-cost-daily-150-cap | ~$0.001/day | Cost Explorer API query ($0.01/1000 queries) |
| nightly-pmf-d7 | ~$0.05-0.10/day | DynamoDB scan of 302 items (cheap); CloudWatch PutMetricData |
| nightly-prompt-eval | ~$0.10/run | 10 Bedrock Haiku calls per run |
| titan-s3-backup-nightly | ~$0.10-0.50/mo | S3 PUT operations for ~1000-2000 files/night |
| swarm-health-orchestrator | ~$0.01/day | CloudWatch PutMetricData (dead-man heartbeat) at 15-min intervals = 96/day |
None of these are egregious or redundant with each other. MTD AWS spend is $69.70 (2026-04-26), daily avg $5.46, forecast $73.58 rest-of-month — well within $150/mo cap. YELLOW tier (46% of cap).
The only cost efficiency win available: reducing swarm-health-orchestrator from 15m to, say, 30m would halve the CloudWatch PutMetricData calls from 96/day to 48/day. This saves ~$0.00 at current volumes — not worth the reduced truncation detection speed.
---
titan-revive-watch-1m frequency → 5 minType: Schedule change only, no code changes
Work required: Edit one line in the scheduled task
Rationale: 99.9% no-op. Fires ~1440 times/day, does real work once every few days. 5-min cadence has zero functional impact on the revive flow since it takes Harnoor >5 min to notice a dead Claude instance anyway.
Savings: 1152 sessions/day eliminated. Significant reduction in Claude Code session churn.
Risk: Low. If revive request waits up to 4 extra minutes, functionally unnoticeable.
titan-inbox-watch to 15 minType: Schedule change only
Work required: Edit one line
Rationale: Web-bridge commands (source=web) are file-based — titan_bridge.py writes directly to inbox-queue.jsonl. The Gmail poll interval has no bearing on web-bridge latency. Only Gmail thread polling benefits from fast cadence, and real Gmail commands arrive rarely (2 in the last 5 days). 2-minute cadence creates 720 sessions/day for near-zero Gmail signal.
Savings: 624 sessions/day eliminated (from 720 to 96).
Risk: Gmail responses may take up to 15 min instead of 2 min. Acceptable — these are async commands.
claude-code-audit-every-6h to every 12hType: Schedule change only
Work required: Edit cron from 17 /6 to 17 /12
Rationale: Audit cadence log shows 20+ runs in 4 days, every run returns n_recs=3 m_regressions=0. The recommendations are stable (same 3 patterns cycle after cycle). Claude Code releases don't ship every 6 hours — they ship weekly. The audit is running 4x per day and producing redundant memos that accumulate in F:/TITAN/plans/advisors/. As of 2026-04-26 there are 16 claude-code-audit-*.md files in that directory.
Savings: 2 fewer SCOUT agent dispatches per day. Reduces memo accumulation by 50%.
Risk: Might miss a CC release by up to 12h instead of 6h. Acceptable — CC releases are announced publicly; any >12h gap is negligible.
titan-nightly-reindex from 3:33 AM to 4:53 AMType: Schedule change only
Work required: Edit one line
Rationale: The SKILL.md itself notes this ordering problem. Reindex currently fires BEFORE feed, meaning new staging intel is never indexed before the 5:27 AM PA email. Correct order: feed (4:33 AM) → reindex (4:53 AM) → PA email (5:27 AM). 20-minute gap gives the feed time to write files; 34-minute gap before PA email gives RAG index time to rebuild.
Savings: The PA email's INTELLIGENCE BRIEFLET section will actually contain fresh, searchable intel. This is a correctness fix, not just optimization.
Risk: Zero. Reindex at 4:53 AM is still 34 min before the PA email reads it.
agentic-247-watchdog from 30 min to 45 minType: Schedule change only
Work required: Edit one line
Rationale: The watchdog log shows 80+ consecutive WARN entries from the same 3-4 persistent issues (heartbeat creds-expired, llm-costs.jsonl stale, AKIA in old session memory). The watchdog is correctly identifying these as persistent rather than acute — and it already correctly suppresses email escalation after the 3rd consecutive WARN. Running at 30 min vs 45 min provides no additional detection capability since the persistent WARNs are known and unfixable at the watchdog layer. Real security events (new AKIA exposure, bypassPermissions drift, 0-byte truncations) would be caught within 45 min — acceptable for a non-production machine.
Savings: 32 sessions/day → 21 sessions/day. 11 sessions/day eliminated.
Risk: A truly new security event detected up to 15 min later. Acceptable given the machine is Harnoor's personal Windows laptop.
titan-daily-newsletter schedule to fire after 5:30 AMType: Schedule specification (currently unspecified)
Work required: Set explicit schedule on the task
Rationale: Newsletter SKILL.md says "if staging is empty, run a quick /feed auto first." If newsletter fires before 4:33 AM feed, it triggers an unscheduled second feed run, duplicating work and potentially writing duplicate staging entries. Setting newsletter to fire at 6:00 AM (after feed at 4:33 AM and after PA email at 5:27 AM) eliminates this risk.
Savings: Eliminates occasional duplicate feed runs. Clarifies the daily pipeline order.
Risk: Zero. Newsletter doesn't need to be early-morning.
---
titan-daily-backup and titan-s3-backup-nightlyDo not merge into a single backup task.
Why: They protect against different failure modes. Local backup (E: drive) allows fast same-day recovery from accidental deletion. S3 backup protects against physical hardware loss. If both ran from a single script that failed, Harnoor would have zero backup coverage. The failure mode of one should NOT mask the other. Separate monitoring guarantees that a failure of the S3 backup path doesn't silently skip the local backup.
agentic-247-watchdog and swarm-health-orchestratorDo not merge.
Why: The watchdog is read-only and observes the orchestrator's log. The orchestrator can spawn agents and remediate. Merging them would make the observer and the actor the same process — if it crashes, both observation and remediation are lost simultaneously. The separation ensures that even if the orchestrator fails, the watchdog still fires and alerts.
agentic-247-watchdog and titan-heartbeat-monitor-15mDo not merge.
Why: The heartbeat monitor is intentionally simpler and more robust. It runs a single Python script against a fixed file list. The watchdog is a complex multi-step Claude-based analysis. If the Claude Code runtime is broken, the watchdog won't fire — but titan_heartbeat_monitor.py is a standalone Python script that runs outside the Claude Code session model. Merging would eliminate TITAN's out-of-band liveness detector.
nightly-report-writer and titan-daily-pa-emailDo not merge.
Why: The report writer uses Haiku only (budget $0.05). The PA email requires more intelligence for the briefing content. The nightly report is a data-assembly task; the PA email is a communication task. If they merged and failed, Harnoor would receive neither the report data NOR the email. Separation allows the report to be written successfully even if the email step fails, and vice versa.
titan-daily-improve (DARWIN daily) and titan-monthly-evolve (DARWIN monthly)Do not merge.
Why: The improve task is intentionally limited to ONE proposal per day to enforce accountability. The evolve task does macro pattern mining. Running them together would either overwhelm the daily improve with pattern data it doesn't need, or under-use the monthly analysis. Their failure modes are also different: improve failing means no daily proposal (acceptable); evolve failing means no monthly skill roadmap (needs to alert).
---
| Task | Current Schedule | Proposed Schedule | Purpose (one line) |
|------|-----------------|------------------|-------------------|
| titan-revive-watch-1m | Every 1 min | Every 5 min | Spawn Claude if revive flag present |
| titan-inbox-watch | Every 2 min | Every 15 min | Gmail + web-bridge command processor |
| titan-bridge-watchdog | Every 5 min | Every 10 min | Keep bridge running on port 8765 |
| silentinfinity-chat-smoke-10m | Every 10 min | Keep 10 min | SI endpoint smoke test (<11 min SLA) |
| titan-heartbeat-monitor-15m | Every 15 min | Keep 15 min | Out-of-band TITAN liveness + SES alert |
| swarm-health-orchestrator | Every 15 min | Keep 15 min | Detect and respawn truncated agents |
| agentic-247-watchdog | Every 30 min | Every 45 min | Full security/cost/integrity audit |
| aws-cost-daily-150-cap | 9:00 AM UTC daily | Keep | AWS MTD cost report email |
| titan-agent-utilization-daily | 9:00 AM daily | Keep | Sub-agent utilization report |
| titan-daily-feed | 4:33 AM daily | Keep | ORACLE intel ingestion → staging |
| titan-nightly-reindex | 3:33 AM daily | 4:53 AM daily | RAG index rebuild (must follow feed) |
| titan-daily-pa-email | 5:27 AM daily | Keep | Morning briefing email to Harnoor |
| nightly-report-writer | 5:00 AM daily | Keep | Assemble overnight agent work summary |
| titan-daily-monologue | Daily (unspecified) | Set to 11:30 PM | Journal turns, mood, curiosities |
| titan-daily-improve | Daily (unspecified) | Set to 9:30 AM | DARWIN micro-improvement proposal |
| titan-daily-backup | ~11:23 PM daily | Keep | Local E: backup with git snapshot |
| titan-daily-log-rotation | 11:52 PM daily | Keep | Log rotation via bridge API |
| titan-daily-newsletter | Daily (unspecified) | Set to 6:00 AM | The Agent Stack newsletter via SES |
| nightly-pmf-d7 | Nightly (unspecified) | Set to 1:00 AM | SI Day-7 return rate → CloudWatch |
| nightly-prompt-eval | Nightly (unspecified) | Set to 2:00 AM | SI prompt regression test |
| titan-scan-local-md-nightly | Nightly (unspecified) | Set to 1:30 AM | Walk drives for .md files, build index |
| titan-s3-backup-nightly | 2:30 AM daily | Keep | Disaster recovery to S3 |
| claude-code-audit-every-6h | Every 6h | Every 12h | SCOUT CC architecture audit vs SI+TITAN |
| titan-weekly-dream | Weekly | Keep Sunday 2:11 AM | Memory consolidation (VAULT) |
| titan-weekly-benchmark | Sunday 6:17 AM | Keep | TITAN health index benchmark |
| titan-weekly-review | Sunday 8:00 PM | Keep | 7-domain life scorecard email |
| titan-monthly-evolve | Monthly | Keep | DARWIN macro pattern mining + skill proposals |
---
1. aws-cost-daily-150-cap SES email broken since 2026-04-21 — WinError 10061 means the script can't reach the SES endpoint (likely via titan_bridge.py at 8765). The bridge watchdog should keep it up, but the timing at 9:00 AM UTC may be catching a restart window. Check if aws_cost_daily.py is calling SES via the bridge vs. directly via boto3.
2. llm-costs.jsonl stale since 2026-04-19 — The watchdog has flagged this 70+ times. This file is not written by any scheduled task — it's a server responsibility. The TITAN bridge or server is not logging LLM costs anymore. Action: check titan_bridge.py or server logging config.
3. nightly-prompt-eval was ERROR on Apr 24-25 — Recovered Apr 26. Root cause unknown. Check F:/projects/innerverse/backend/eval/ for any recent changes.
4. titan-agent-utilization-daily shows 0 runs for all agents — No entries in F:/TITAN/state/agent-runs.jsonl from named sub-agents. Agents are running (watchdog confirms swarm activity) but not logging to this file. Action: instrument SCOUT/VAULT/FORGE/ORACLE/DARWIN dispatch hooks to write to agent-runs.jsonl.
5. titan-nightly-reindex ordering bug — Confirmed. Reindex fires at 3:33 AM, feed fires at 4:33 AM. Reindex should fire at 4:53 AM. This is Consolidation Proposal C4 and takes 30 seconds to fix.
---
Audit completed: 2026-04-26 by SCOUT (A065)
Tasks read: 27/27
Scripts verified: 16 confirmed existing, 11 skill/inline