[Feature]: Add the project event timeline and audited control commands

[roomote-community]

Problem

Project mutations, task outcomes, branch actions, and user controls need durable, replayable history before automation can safely depend on them.

Proposed behavior

Add append-only project events with source and observed timestamps plus idempotent control commands for pause, pause-after-current, resume, cancel, retry, replan, priority/dependency changes, approval, and merge requests. Render the Activity tab with arbitrary dates.

Reuse task lifecycle states, existing mutation/idempotency patterns, and date/analytics components.

Acceptance criteria

• High-impact project mutations produce one idempotent event.
• Duplicate webhooks/commands do not duplicate effects.
• Durable pause state survives process restarts.
• Timeline distinguishes event time from ingestion time.
• Exact date and timezone filtering is supported.

Dependencies

• [Feature]: Add the project planning domain model and authorization foundation #1037
• [Feature]: Add project item acceptance, integration PRs, and final delivery #1042

[roomote-community]

I've analyzed this issue and here's my proposed implementation plan:

1. Build on the project model from [Feature]: Add the project planning domain model and authorization foundation #1037 with additive Drizzle tables in packages/db/src/schema.ts: an append-only project_events ledger, an idempotent project_commands inbox/result record, and durable per-project control state. Store a deterministic event/command key, event kind, source, actor, subject, payload, occurredAt (source time), and observedAt (ingestion time); add uniqueness on (projectId, eventKey) / (projectId, idempotencyKey) and timeline indexes. Generate the migration and export server-only helpers through packages/db/src/server.ts, preserving the N-1 rollback guarantee.
2. Add a project command service under the project service boundary introduced by [Feature]: Add the project planning domain model and authorization foundation #1037. In one transaction, authorize the actor using project role grants, atomically claim the idempotency key, lock or compare-and-set the project control row, apply the mutation, append exactly one event, and persist the result returned to duplicate callers. Do not use a read-before-write dedupe check.
3. Define explicit transition rules for pause, pause_after_current, resume, and cancel. Recommended semantics: pause is a durable dispatch pause that immediately blocks new item attempts but does not claim to suspend a running harness; pause-after-current enters a draining state and becomes paused when active attempts settle; resume re-enables dispatch; cancel blocks future work and routes active attempts through the existing task cancellation path. This matches the current runtime, which has durable task/run states and cancellation but no resumable live-process pause primitive.
4. Implement retry, replan, priority/dependency changes, approval, and merge-request commands as adapters over the owning services rather than parallel mutation paths. Retry should create a new linked attempt, replan should create an immutable plan version, dependency updates should retain [Feature]: Add the project planning domain model and authorization foundation #1037's cycle validation, and approval/merge commands should call the acceptance and serialized integration-PR flow from [Feature]: Add project item acceptance, integration PRs, and final delivery #1042. Invalid or stale transitions should return a stable recorded result and must not append a misleading success event.
5. Route every high-impact producer through a shared append helper with deterministic source keys: project/plan/milestone/item changes from [Feature]: Add the project planning domain model and authorization foundation #1037, task attempt lifecycle and cancellation from [Feature]: Link project plan items to existing Roomote task execution and controls #1041, and acceptance, branch/PR/check, reversal, and final-delivery changes from [Feature]: Add project item acceptance, integration PRs, and final delivery #1042. Reuse packages/db/src/lib/sync-task-state.ts lifecycle derivation and the atomic claim pattern in apps/api/src/handlers/github/recordWebhook.ts; webhook-derived keys should include provider plus delivery/event identity so redelivery and concurrent processing converge on one effect.
6. Expose authorized project event queries and command mutations through a dedicated apps/web/src/trpc/commands/projects/ module and the protected router in apps/web/src/trpc/routers/_app.ts. Validate command-specific payloads with discriminated schemas, carry actor/source/idempotency metadata server-side, paginate the event ledger with a stable (occurredAt, id) cursor, and never accept authorization-sensitive actor fields from the browser.
7. Complete the Activity tab shell introduced by [Feature]: Add the Projects dashboard and manual project setup #1038 with a chronological timeline that identifies event type, actor/source, affected entity, and both source and ingestion timestamps when they differ. Add arbitrary from/to date inputs plus an IANA timezone selector (defaulting to the deployment timezone), convert inclusive local calendar dates to UTC query boundaries on the server, and preserve the selected range/timezone in URL state. The existing TaskFilters.tsx and analytics controls only support preset rolling windows, so this should be a project-specific exact-range control while reusing their filter styling and date/analytics formatting patterns.
8. Add focused tests: schema constraints and append-only behavior; concurrent duplicate command/webhook claims; authorization and every valid/invalid transition; pause-state recovery from a fresh service process; task/PR/reversal producer mappings; retry/replan lineage; pagination ordering when occurrence and ingestion differ; and exact-date filtering across UTC offsets and DST boundaries. Add component tests for timeline rendering, dual timestamps, empty/error states, and URL-backed filters.

This approach makes the event ledger the audit/replay record while keeping a separate durable control projection for restart-safe decisions, and it keeps existing task, planning, acceptance, and PR services as the only owners of their mutations. Implementation should follow #1037 and #1042 (and consume the Activity shell from #1038 plus task linkage from #1041) so this work integrates with their final schemas instead of duplicating them.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.