[RFC / Design] Support for Standalone / Ad-hoc Tasks

[espdesign]

Overview

Currently, tasks must be bound to an existing project container (TaskTable.project_id is a non-null foreign key). Although the UI and authorization layers have initial scaffolding for standalone tasks (allow_standalone, can_create_standalone, and default TASK-# references), creating one fails at runtime.

This issue tracks the discussion and technical design decisions needed to enable standalone / ad-hoc tasks across the system.

Problem Statement

Users need a way to track quick one-off chores, ad-hoc bugs, or general server tasks without having to create or choose a full project container.

Currently:

• TaskTable.project_id in PostgreSQL has nullable=False.
• Task domain model requires project_id: UUID.
• TaskService.create_task() enforces if not resolved_project_id: raise ValidationError("A project container must be specified for every task.").
• Short ID allocation (prefix-number) assumes an active project row exists to increment next_task_number.

---

Design Options Under Consideration

Option A: Default "Standalone" / "General" Project Container (Recommended)

Automatically create a default project named Standalone (or General Tasks) per guild with prefix TASK.

• Pros:
  • Zero DB schema changes: No nullable migration on tasks.project_id or foreign key adjustments.
  • Existing atomic allocation: Reuses existing next_task_number counter to automatically generate TASK-1, TASK-2, TASK-3 with full concurrency safety.
  • Compatibility: Tech trees, burndown metrics, outbox events, and task board views immediately work without needing if project_id is None guards across queries.
  • Task Board scoping: Users can filter directly to [TASK] Standalone on the board to view all ad-hoc tasks.
  • Channel routing: Since the default project's discord_channel_id is None, tasks post directly in whichever channel/forum the user creates them in.
• Questions / Decisions:
  • Naming & prefix: Standalone vs General vs Inbox; prefix TASK vs STD vs GEN.
  • Visibility: Should it be hidden from /project list or categorized as a system/general container?
  • Provisioning: Automatically ensure existence on guild join, seeding, or first use.

Option B: True Nullable project_id

Make tasks.project_id nullable across the database and models.

• Pros:
  • Tasks truly have no parent project entity in the database.
• Cons & Required Changes:
  • Alembic migration to drop NOT NULL constraint on tasks.project_id.
  • Need a new guild-level sequence / counter mechanism (e.g. guild_task_sequences table) to atomically allocate TASK-# IDs.
  • Must update all aggregations, queries, outbox workers, and board views to handle None project IDs.

---

Next Steps

• Decide between Option A (Default Project) and Option B (Nullable Schema).
• Define UX for /task create (making project_name optional to fallback to standalone).
• Wire up interactive menus (TaskMenuView.standalone_btn and HubTaskProjectSelectView).

[espdesign]

Important Access & Permission Consideration: Role-Based Creation

A critical concern with standalone tasks is permissions: giving all server members open access to create standalone tasks is problematic (risks spam, unvetted chores, and board clutter).

Potential Solutions:

1. Configurable Role-Based Access:
   • Allow server managers to assign which specific Discord roles (or minimum role tier) are permitted to create standalone tasks (e.g. /settings standalone-role @Contributor or guild configuration).
2. Current AuthService Pattern:
   • Restrict creation by default to Server Managers and Squad Leads (as currently sketched in AuthService.can_create_task_in_project(user, None)).
3. If using Option A (Default Project):
   • Since projects already support mapped contributor Discord roles via project.discord_role_id or linked squads, a default standalone project can simply have a mapped role or squad assigned to it to strictly gate who can post tasks into it.

[espdesign]

Milestone Update: Deferred to Post-Alpha

Per team alignment and the updated Alpha Release Roadmap (#29), standalone / ad-hoc task support is deferred to post-Alpha.

Rationale:

• Preserves the architectural boundaries documented in ADR 0002 and CONTEXT.md (mandatory project containers, sequential short IDs, and catch-all default projects).
• Eliminates major database schema migrations (tasks.project_id nullable + guild sequence counters) and complex role-gating permissions from the critical path of the Alpha release.
• Allows the Alpha milestone to stay focused on onboarding workflows ([Feature]: Server Onboarding Wizard (/pm setup), Welcome Flow, and Diagnostic Check (/pm doctor) #25), dependency guards & unblock notifications ([Feature]: Dependency Unblock Notifications (TASK_UNBLOCKED Event & Outbox Dispatch) #26, [Feature]: Dependency Invalidation Guard (Blocked State Start Warnings) #28), and rate-limiting guards ([Feature]: Rate-Limit Protection & Debounce for Task Thread Renaming #32, [Improvement]: Resilient Slash Command Syncing & Startup Rate-Limit Protection #33).