{
"tasks": [
{
"id": "T1",
"title": "Handle partial failures in HL7 batch ingest",
"description": "When a batch of HL7 messages fails halfway, currently we either commit all or none. Need per-message outcome tracking with retry.",
"area": "backend",
"effort_days": 3,
"assignee": "Omar Hassan",
"status": "InReview",
"progress": 100,
"due_day": 4,
"concern": null,
"notes": [
"Day 1 10:00: ",
"Day 1 10:30: ",
"Day 1 11:00: ",
"Day 1 12:00: ",
"Day 1 submitted: ",
"Day 1 14:00: ",
"Review: Kickoff",
"Day 5 14:30: I built the per-message outcome tracking and retry logic for HL7 batch ingest. Instead of a transactional all-or-nothing commit, the ingest …",
"Day 5 submitted: "
]
},
{
"id": "T2",
"title": "Admin console: audit log viewer",
"description": "Ops needs to see who changed what and when. Simple paginated table with filters, no fancy stuff.",
"area": "frontend",
"effort_days": 2,
"assignee": "Elena Vasquez",
"status": "InReview",
"progress": 100,
"due_day": 3,
"concern": null,
"notes": [
"Day 1 10:30: ",
"Day 1 11:00: ",
"Day 1 submitted: ",
"Day 3 11:00: I built the audit log viewer for ops. It's a plain, paginated table with filters for actor, action, and date range. No animations, no cards,…",
"Day 3 15:00: Sketched the audit log viewer on paper first. I want it to be boring in the best way: a clean table, a filter bar, and a pagination footer w…",
"Review: Priya Nair's Migration dry-run mode needs explicit rollback simulation steps added to the risk assessment.",
"Day 4 11:00: I've drafted the AuditLogViewer component for the admin console. It's a straightforward, paginated table with date and actor filters. I've k…",
"Day 4 submitted: ",
"Day 5 13:00: I'm building the audit log viewer for the admin console. It's a simple paginated table with filters for user, action, and date range. No ani…"
]
},
{
"id": "T3",
"title": "Migration dry-run mode",
"description": "Let Omar's team rehearse a cutover against a copy without writing to production. Flag-gated run with a full report.",
"area": "data",
"effort_days": 3,
"assignee": "Priya Nair",
"status": "InReview",
"progress": 100,
"due_day": 4,
"concern": null,
"notes": [
"Day 1 11:00: ",
"Day 1 11:30: ",
"Day 1 13:00: ",
"Day 1 14:00: ",
"Day 1 submitted: ",
"Day 4 11:30: Built the dry-run mode for T3. The core principle is immutability: the dry-run path must be structurally incapable of writing to production.…",
"Day 4 15:00: T3 is done. I added a `--dry-run` flag to the cutover migration command. In dry-run mode the engine opens a READ-ONLY connection to the stag…",
"Day 4 16:00: For T3, I am implementing a flag-gated dry-run mode in the sync engine. The `--dry-run` flag instructs the migration runner to validate sche…"
]
},
{
"id": "T4",
"title": "Load test: 10k patients record sync",
"description": "We have never sustained this. Generate the load, measure p99, find the ceiling before the hospital does.",
"area": "qa",
"effort_days": 2,
"assignee": "Omar Hassan",
"status": "InReview",
"progress": 100,
"due_day": 3,
"concern": null,
"notes": [
"Day 1 14:30: ",
"Day 1 15:00: ",
"Day 1 submitted: ",
"Day 2 14:30: I built a deterministic load generator and a p99 measurement harness for the sync engine. The generator produces 10k patient records with re…"
]
},
{
"id": "T5",
"title": "Rollback plan for v2.3 deploy",
"description": "One-command rollback with verified backups. No deploy goes out without this.",
"area": "devops",
"effort_days": 1,
"assignee": "Sofia Lindgren",
"status": "ChangesRequested",
"progress": 85,
"due_day": 2,
"concern": null,
"notes": [
"Day 1 14:30: ",
"Day 1 submitted: ",
"Day 1 16:00: I built the rollback script and the runbook so that a v2.3 failure can be reversed in one verified step. The script restores the Postgres du…",
"Day 2 13:00: I built out the rollback runbook for the v2.3 sync engine deploy. It defines a strict pre-deploy checklist that verifies the Postgres dump a…",
"Review: Rollback plan for v2.3 deploy",
"Day 3 15:00: I am treating the v2.3 deploy as a high-risk event until proven otherwise. I have written a strict runbook that enforces a manual verificati…",
"Day 3 submitted: ",
"Day 4 11:30: I built the rollback playbook for v2.3 because a deploy without a rollback plan is just a controlled explosion, and I refuse to ship that. I…",
"Review: Rollback plan for v2.3 deploy"
]
},
{
"id": "T6",
"title": "Empty states for console search",
"description": "Searching with no results currently shows a blank void. Needs helpful copy and a reset action.",
"area": "frontend",
"effort_days": 1,
"assignee": "Elena Vasquez",
"status": "InReview",
"progress": 100,
"due_day": 2,
"concern": null,
"notes": [
"Day 1 15:00: ",
"Day 1 15:00: ",
"Day 2 12:00: I sketched the empty state on paper first. The blank void is unacceptable for a hospital console; a clinician staring at nothing cannot tell…",
"Day 2 submitted: ",
"Review: Admin console empty states implementation",
"Day 2 13:30: I shipped the empty-state component for the console search panel. The blank void was unacceptable — a hospital admin staring at nothing duri…",
"Day 2 submitted: ",
"Day 3 13:00: I built the empty-state component for the console search page. When the search returns zero records, the UI now renders a friendly illustrat…",
"Day 4 16:30: I sketched the no-results state on paper before touching code. A blank void is a UX failure, not a feature gap. I added a dedicated EmptySea…"
]
},
{
"id": "T7",
"title": "FHIR R4 validation on inbound payloads",
"description": "Reject malformed FHIR early with a clear error the hospital IT can act on, instead of failing deep in the pipeline.",
"area": "backend",
"effort_days": 3,
"assignee": "Aiko Tanaka",
"status": "InReview",
"progress": 100,
"due_day": 4,
"concern": null,
"notes": [
"Day 1 15:00: ",
"Day 1 15:30: I built a FHIR R4 inbound validator in Rust that rejects malformed payloads before they hit the sync engine. It uses serde_json to parse int…",
"Day 2 09:30: I started T7 by writing a Rust module that validates a FHIR R4 Bundle before it enters our sync pipeline. It checks the required `type` fiel…",
"Day 2 10:30: I built a strict FHIR R4 inbound payload validator in Rust that rejects malformed resources before they hit the sync pipeline. It uses the `…",
"Day 2 submitted: ",
"Day 4 11:30: I built the inbound FHIR R4 validation layer for task T7 to stop malformed payloads before they hit the sync pipeline. I created a Rust vali…"
]
},
{
"id": "T8",
"title": "Data quality dashboard for Omar",
"description": "Row counts, drift checks, last successful sync per customer — one page, auto-refresh.",
"area": "data",
"effort_days": 2,
"assignee": "Marcus Chen",
"status": "InReview",
"progress": 100,
"due_day": 3,
"concern": null,
"notes": [
"Day 2 12:00: I reviewed the task for the data quality dashboard and decided to build it as a simple, read-only view rather than a complex interactive too…",
"Day 2 13:30: I'm not building a dashboard; I'm building a health check. A dashboard is a UI problem; this is a data integrity problem. If a customer's ro…",
"Day 2 submitted: ",
"Day 4 14:00: Built the data quality dashboard backend and frontend. Created a Rust endpoint that queries Postgres for row counts, drift metrics, and last…",
"Day 4 14:30: I reviewed T8 and decided the simplest thing that could work is a read-only SQL view plus a lightweight TypeScript/React page that polls it …",
"Day 5 13:00: For T8, I'm handing Omar the Postgres migration and a minimal React component for the data quality dashboard. I'm intentionally keeping it b…"
]
},
{
"id": "T9",
"title": "Scope: customer-facing status page",
"description": "Sales wants a public status page. Product needs to decide what we actually commit to before building it.",
"area": "product",
"effort_days": 2,
"assignee": "Marcus Chen",
"status": "InReview",
"progress": 100,
"due_day": 3,
"concern": null,
"notes": [
"Day 2 15:00: James and I sat down to define the status page scope before any code is written. I pushed back on building a live dashboard; that's a moving…",
"Day 2 16:00: Sales wants a status page, but I'm not building a UI until we know what we're actually promising. If we say \"99.99% uptime\" we're signing a …",
"Day 2 submitted: "
]
},
{
"id": "T10",
"title": "Onboarding doc for Aiko's first engine task",
"description": "Walk through the sync engine architecture so the next junior doesn't have to reverse-engineer it.",
"area": "backend",
"effort_days": 1,
"assignee": "Aiko Tanaka",
"status": "InReview",
"progress": 100,
"due_day": 2,
"concern": null,
"notes": [
"Day 1 14:00: ",
"Day 1 submitted: ",
"Review: email_from_Aiko_Tanaka",
"Day 1 15:00: ",
"Day 1 15:00: I finally got the sync engine architecture doc out of my head and onto the page. I walked through the Rust crate structure, the Postgres bat…",
"Day 1 submitted: ",
"Review: Aiko Tanaka Onboarding Doc",
"Day 2 11:30: I drafted the onboarding doc for T10 to help the next junior engineer understand the sync engine without reverse-engineering it. I focused o…",
"Day 2 submitted: ",
"Day 2 13:30: I've drafted the onboarding doc for T10 to ensure the next junior engineer doesn't have to reverse-engineer the sync engine. I focused on th…",
"Day 3 09:30: I finally finished the onboarding doc for the sync engine and honestly felt a bit of relief when I realized I actually understood the whole …",
"Day 5 11:30: I drafted the onboarding doc for T10 to ensure the next junior engineer understands the sync engine's fault tolerance without reverse-engine…",
"Day 5 16:00: I drafted the onboarding doc for the sync engine, focusing on the batch processing flow and the critical idempotency checks that prevent dup…"
]
}
],
"day": 5,
"sim_minutes": 6720.0
}