Feature: Issue Scheduling Fields (scheduled_at / due_at)

[consentculture]

Summary

Add optional scheduled_at and due_at DateTime fields to issues, enabling task scheduling workflows. scheduled_at marks when an issue becomes actionable; due_at is the hard deadline. The crosslink next command filters out not-yet-scheduled issues, boosts overdue issues by +100, and prints a warning when a deadline is within 1 day. Both fields propagate through the full event-sourced pipeline: CLI flags, events, shared writer, compaction, materialization, hydration, and SQLite.

Requirements

• REQ-1: Add scheduled_at: Option<DateTime<Utc>> and due_at: Option<DateTime<Utc>> fields to the Issue data model across all representation layers (Issue struct, IssueFile, CompactIssue, HydratedIssue, SQLite schema).
• REQ-2: Add a SchedulingUpdated T2 event variant to the Event enum for post-creation scheduling changes, following the same pattern as StatusChanged (always overwrites both fields).
• REQ-3: Add optional scheduled_at and due_at fields to the IssueCreated event variant so scheduling can be set atomically at creation time (matching the existing pattern where IssueCreated carries initial field values like labels).
• REQ-4: Add --scheduled and --due CLI flags to create, quick, and update commands, accepting YYYY-MM-DD or full RFC 3339 datetime input.
• REQ-5: Add --no-scheduled and --no-due CLI flags to update for clearing previously-set dates.
• REQ-6: crosslink next must filter out issues whose scheduled_at is in the future (not yet actionable).
• REQ-7: crosslink next must boost overdue issues (due_at < now) by +100 in the scoring algorithm.
• REQ-8: crosslink next must print a warning alongside any recommended issue whose due_at is within 1 day.
• REQ-9: crosslink show must display Scheduled and Due fields when set, formatted as YYYY-MM-DD.
• REQ-10: Full backward compatibility: existing issues without scheduling dates, existing event logs without scheduled_at/due_at fields, and existing checkpoint state must continue to work via #[serde(default)].
• REQ-11: Date parsing convention: YYYY-MM-DD input for --scheduled is parsed to T00:00:00Z (start of day); YYYY-MM-DD input for --due is parsed to T23:59:59Z (end of day). Full RFC 3339 datetime input (e.g. 2026-03-20T14:00:00Z) is parsed directly, bypassing the start/end-of-day convention.
• REQ-12: Subissue constraint: if --scheduled or --due is provided together with --parent, the CLI must reject with an error: "Scheduling dates apply to parent issues, not subissues." Scheduling fields are a property of the deliverable (parent issue), not the implementation breakdown (subissues).

Acceptance Criteria

• AC-1: crosslink create "title" --scheduled 2026-03-20 --due 2026-03-25 creates an issue with scheduled_at stored as 2026-03-20T00:00:00Z and due_at stored as 2026-03-25T23:59:59Z. (REQ-3, REQ-4, REQ-11)
• AC-2: crosslink quick "title" -p high --due 2026-03-25 creates an issue with due date set and scheduled_at as None. (REQ-3, REQ-4, REQ-11)
• AC-3: crosslink update <id> --scheduled 2026-03-20 sets scheduled_at without changing due_at. A SchedulingUpdated event is emitted carrying both fields (current due_at preserved via read-before-write). (REQ-2, REQ-4)
• AC-4: crosslink update <id> --no-due clears due_at to None. Passing --due X and --no-due simultaneously is rejected by clap conflicts_with. (REQ-5)
• AC-5: crosslink show <id> on an issue with scheduled_at = 2026-03-20T00:00:00Z and due_at = 2026-03-25T23:59:59Z prints Scheduled: 2026-03-20 and Due: 2026-03-25. (REQ-9)
• AC-6: crosslink show <id> on an issue with no scheduling dates does not print Scheduled/Due lines. (REQ-9)
• AC-7: crosslink next with an issue whose scheduled_at is tomorrow does not include that issue in the results. (REQ-6)
• AC-8: crosslink next with a medium overdue issue and a medium non-overdue issue ranks the overdue issue higher (score 300 vs 200). (REQ-7)
• AC-9: crosslink next with an issue due in 6 hours prints a warning line like Due in 6 hours alongside the recommendation. (REQ-8)
• AC-10: A SchedulingUpdated event written to the event log is correctly processed by compaction: the CompactIssue state reflects the new dates, and materialized issue.json contains the fields. (REQ-2)
• AC-11: Scheduling dates survive a full round-trip: create with dates, compact, materialize to JSON, hydrate to SQLite, query via db.get_issue() — all dates match. (REQ-1, REQ-10)
• AC-12: Deserializing an existing IssueCreated event (without scheduled_at/due_at) succeeds with both fields defaulting to None. Existing checkpoint state without these fields deserializes correctly. (REQ-10)
• AC-13: If both --scheduled and --due are provided and scheduled > due, the CLI prints a warning (not an error) before proceeding. (REQ-4, REQ-11)
• AC-14: crosslink create "subtask" --parent 1 --due 2026-03-25 is rejected with an error message stating that scheduling dates apply to parent issues, not subissues. (REQ-12)
• AC-15: crosslink quick "subtask" --parent 1 --scheduled 2026-03-20 is rejected with the same error. (REQ-12)
• AC-16: crosslink next with an issue that has no scheduled_at and no due_at includes that issue in results (dateless issues are always eligible). (REQ-6, REQ-10)
• AC-17: crosslink next with a high priority issue (no dates) and a medium priority issue (with scheduled_at in the past, due_at in the future, not overdue) recommends the high issue (scheduling dates alone do not override priority). (REQ-7, REQ-10)
• AC-18: crosslink next with a dateless medium priority issue does not receive the +100 overdue boost (only issues with due_at < now get boosted). (REQ-7, REQ-10)
• AC-19: An issue created before the feature (no scheduled_at/due_at columns in its original SQLite row or JSON) displays correctly in crosslink show with no Scheduled/Due lines and no errors, and appears normally in crosslink next. (REQ-10)
• AC-20: crosslink create "title" --due 2026-03-20T14:00:00Z stores due_at as 2026-03-20T14:00:00Z exactly, not adjusted to T23:59:59Z. Full RFC 3339 input bypasses the start/end-of-day convention. (REQ-11)

Architecture

Date Type and Input Parsing

The fields use DateTime<Utc> to match the codebase's existing timestamp pattern (models.rs:12-14, issue_file.rs:26-29). A custom clap value_parser function accepts:

1. ISO 8601 date YYYY-MM-DD — parsed via NaiveDate::parse_from_str then converted to DateTime<Utc>. For --scheduled: T00:00:00Z (start of day). For --due: T23:59:59Z (end of day).
2. Full RFC 3339 datetime (e.g. 2026-03-20T14:00:00Z) — parsed directly, bypassing the start/end-of-day convention. This allows precise scheduling when needed.

Display in show uses %Y-%m-%d format since the time component is typically not meaningful for scheduling.

Layer 1: Event System — crosslink/src/events.rs

IssueCreated (lines 56-67) gains two optional fields with #[serde(default)] for backward compatibility:

IssueCreated {
    uuid: Uuid,
    title: String,
    description: Option<String>,
    priority: String,
    labels: Vec<String>,
    parent_uuid: Option<Uuid>,
    created_by: String,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    scheduled_at: Option<DateTime<Utc>>,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    due_at: Option<DateTime<Utc>>,
}

SchedulingUpdated is a new T2 (causal) variant (#14). It follows the StatusChanged pattern: always carries the full new state of both fields. None means "not set / cleared". The CLI reads the current issue state before emitting, so unchanged fields are preserved.

SchedulingUpdated {
    uuid: Uuid,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    scheduled_at: Option<DateTime<Utc>>,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    due_at: Option<DateTime<Utc>>,
}

Layer 2: Checkpoint State — crosslink/src/checkpoint.rs

CompactIssue (lines 63-87) gains:

#[serde(default, skip_serializing_if = "Option::is_none")]
pub scheduled_at: Option<DateTime<Utc>>,
#[serde(default, skip_serializing_if = "Option::is_none")]
pub due_at: Option<DateTime<Utc>>,

#[serde(default)] ensures existing checkpoint files without these fields deserialize correctly.

Layer 3: Compaction — crosslink/src/compaction.rs

The apply() function (lines 313+) gains:

In the IssueCreated arm (line 336): set scheduled_at and due_at from the event fields when constructing the CompactIssue.

New arm for SchedulingUpdated:

Event::SchedulingUpdated { uuid, scheduled_at, due_at } => {
    if let Some(issue) = state.issues.get_mut(uuid) {
        issue.scheduled_at = *scheduled_at;
        issue.due_at = *due_at;
        issue.updated_at = envelope.timestamp;
        changed_issues.insert(*uuid);
    }
}

The compact_to_issue_file() function (lines 566-586) propagates the two new fields to IssueFile.

Layer 4: Issue File — crosslink/src/issue_file.rs

IssueFile (lines 13-45) gains:

#[serde(default, skip_serializing_if = "Option::is_none")]
pub scheduled_at: Option<DateTime<Utc>>,
#[serde(default, skip_serializing_if = "Option::is_none")]
pub due_at: Option<DateTime<Utc>>,

Layer 5: Models — crosslink/src/models.rs

Issue struct (lines 5-15) gains:

pub scheduled_at: Option<DateTime<Utc>>,
pub due_at: Option<DateTime<Utc>>,

Layer 6: Database — crosslink/src/db.rs

Schema migration (bump SCHEMA_VERSION from 15 to 16): add two nullable TEXT columns to the issues table:

ALTER TABLE issues ADD COLUMN scheduled_at TEXT;
ALTER TABLE issues ADD COLUMN due_at TEXT;

HydratedIssue (lines 81-93) gains:

pub scheduled_at: Option<&'a str>,
pub due_at: Option<&'a str>,

insert_hydrated_issue (lines 1422-1429): add scheduled_at and due_at to the INSERT statement.

create_issue_with_parent (lines 407-436): add optional scheduled_at and due_at parameters, included in INSERT if provided.

update_issue (lines 541-595): add optional scheduled_at and due_at parameters. When provided, dynamically append to the SET clause (same pattern as title/description/priority).

get_issue and query methods: update SELECT statements and parse_issue_row() to read the two new columns.

Layer 7: Hydration — crosslink/src/hydration.rs

In the hydration loop (around line 161), convert IssueFile.scheduled_at and due_at to RFC 3339 strings and pass through HydratedIssue into insert_hydrated_issue.

Layer 8: Shared Writer — crosslink/src/shared_writer.rs

create_issue (lines 366-434): accept optional scheduled_at and due_at parameters. Include in the IssueFile JSON and in the IssueCreated event fields.

New method update_scheduling: reads the current issue file, merges the requested changes (set or clear each field), writes back, emits a SchedulingUpdated event, compacts, and pushes. Follows the update_issue pattern.

Layer 9: CLI — crosslink/src/main.rs

Create (lines 433-457) and Quick (lines 460-478) structs gain:

#[arg(long, value_parser = parse_scheduled_date)]
scheduled: Option<DateTime<Utc>>,
#[arg(long, value_parser = parse_due_date)]
due: Option<DateTime<Utc>>,

Update (lines 507-520) gains:

#[arg(long, value_parser = parse_scheduled_date)]
scheduled: Option<DateTime<Utc>>,
#[arg(long, conflicts_with = "scheduled")]
no_scheduled: bool,
#[arg(long, value_parser = parse_due_date)]
due: Option<DateTime<Utc>>,
#[arg(long, conflicts_with = "due")]
no_due: bool,

Two parser functions: parse_scheduled_date converts YYYY-MM-DD to T00:00:00Z (start of day); parse_due_date converts to T23:59:59Z (end of day). Both fall back to DateTime::parse_from_rfc3339 for full datetime input. Both return clear error messages on failure.

Update's "at least one field required" validation (in commands/update.rs:16) is extended to also accept scheduling flags.

Layer 10: Commands

commands/create.rs: passes scheduled and due from CLI args through to shared_writer.create_issue(). If --parent is set alongside --scheduled or --due, reject with error before reaching the writer. If both scheduling flags are set and scheduled > due, prints a warning to stderr.

commands/update.rs: determines new scheduling state by reading the current issue, applying the CLI flags (set / clear / leave unchanged), then calling shared_writer.update_scheduling().

commands/show.rs (lines 54-58): after the existing Updated: line, conditionally prints:

Scheduled: 2026-03-20
Due:       2026-03-25

commands/next.rs (lines 48-157):

1. After the subissue and lock filters (line 76), add: if issue.scheduled_at is Some(dt) and dt > Utc::now(), skip (continue). For subissues (where issue.parent_id.is_some()), look up the parent's scheduled_at via db.get_issue(parent_id) and apply the same filter.
2. In the scoring block (line 87), add: if issue.due_at is Some(dt) and dt < Utc::now(), add +100 to score. For subissues, look up the parent's due_at and apply the same boost.
3. In the output block (lines 114-135), after the description preview: if issue.due_at (or parent's due_at for subissues) is Some(dt) and dt - Utc::now() <= Duration::days(1) and dt > Utc::now(), print a warning line with the time remaining (e.g., Due in 6 hours).

Note: crosslink next currently skips subissues entirely (line 67), so the parent lookup only matters if that filter is relaxed in the future. The implementation should still handle it correctly for forward compatibility.

Data Flow Summary

CLI (--scheduled/--due)
  |
  v
SharedWriter.create_issue() / update_scheduling()
  |
  +-- Writes IssueFile JSON (with scheduled_at/due_at)
  +-- Appends IssueCreated or SchedulingUpdated event
  +-- Runs compaction
  |     |
  |     +-- apply(): sets CompactIssue.scheduled_at/due_at
  |     +-- materialize(): CompactIssue -> IssueFile JSON
  |
  +-- hydrate_to_sqlite()
        |
        +-- IssueFile -> HydratedIssue -> SQLite (scheduled_at/due_at TEXT columns)
        |
        +-- db.get_issue() -> Issue struct (with scheduled_at/due_at)
              |
              +-- commands/next.rs: filter, score, warn
              +-- commands/show.rs: display

Open Questions

Q1: Serde annotations on SchedulingUpdated fields

The SchedulingUpdated event "always carries the full new state of both fields" where None means "cleared." Two options for the serde annotations:

Option A (current draft): #[serde(default, skip_serializing_if = "Option::is_none")] — matches the IssueCreated pattern. None fields are omitted from JSON; serde(default) restores them as None on deserialize. Round-trip is correct but the omission makes "intentionally cleared" visually indistinguishable from "field not present" in the event log.

Option B: No skip_serializing_if, just bare Option<DateTime<Utc>> — None serializes as explicit null. The event log shows {"scheduled_at": null, "due_at": "2026-03-25T23:59:59Z"}, making the intent visible. serde(default) is also unnecessary since both fields are always present in new events.

Note: this only affects SchedulingUpdated. The IssueCreated annotations (#[serde(default, skip_serializing_if = "Option::is_none")]) are correct as-is for backward compatibility with existing events.

To resolve: Developer decision during implementation. Edit this section with the chosen approach and remove the <!-- OPEN --> marker.

Out of Scope

• Filtering issue list by scheduled/due dates (list always shows all matching issues regardless of scheduling)
• Recurring / repeating schedule patterns
• Timezone-aware scheduling (all dates are UTC; scheduled at start-of-day, due at end-of-day)
• Calendar integration or external notification systems
• Relative date input (e.g. +3d, tomorrow) — only ISO 8601 date strings accepted
• Subissue-level scheduling dates: scheduling fields are a property of the deliverable (parent issue), not the implementation breakdown (subissues). Subissues inherit their parent's dates implicitly via parent lookup in crosslink next. No separate date fields on subissues.

[consentculture]

Submitted for consideration!

[dollspace-gay]

Feature: Issue Scheduling Fields (scheduled_at / due_at)

Summary

Add optional scheduled_at and due_at DateTime fields to issues, enabling task scheduling workflows. scheduled_at marks when an issue becomes actionable; due_at is the hard deadline. The crosslink next command filters not-yet-scheduled issues, boosts overdue issues, and warns about approaching deadlines. Both fields propagate through the full pipeline: CLI, IssueFile JSON, CompactIssue, SQLite schema, and hydration.

Requirements

• REQ-1: Add scheduled_at: Option<DateTime<Utc>> and due_at: Option<DateTime<Utc>> to Issue (models.rs:5-15), IssueFile (issue_file.rs:13-45), CompactIssue (checkpoint.rs:63-87), HydratedIssue (db/hydration.rs:8-20), and SQLite schema (db/core.rs, SCHEMA_VERSION 15 -> 16).
• REQ-2: Add --scheduled and --due CLI flags to the Create (main.rs:465-489), Quick (main.rs:492-510), and Update (main.rs:557-570) commands. Accept YYYY-MM-DD or full RFC 3339 datetime input.
• REQ-3: Add --no-scheduled and --no-due CLI flags to Update for clearing dates. Use clap conflicts_with to prevent --due + --no-due.
• REQ-4: crosslink next (commands/next.rs:49-157) must filter out issues whose scheduled_at is in the future (not yet actionable), boost overdue issues (due_at < now) by +100, and print a warning when due_at is within 1 day.
• REQ-5: crosslink show (commands/show.rs) must display Scheduled and Due fields when set, formatted as YYYY-MM-DD.
• REQ-6: Date parsing convention: YYYY-MM-DD for --scheduled parses to T00:00:00Z (start of day); for --due parses to T23:59:59Z (end of day). Full RFC 3339 input is parsed directly.
• REQ-7: Subissue constraint: reject --scheduled or --due when --parent is also set, with error: "Scheduling dates apply to parent issues, not subissues."
• REQ-8: Full backward compatibility via #[serde(default)] — existing issues, event logs, and checkpoint state without these fields must continue to work.
• REQ-9: SharedWriter::update_issue (shared_writer/mutations.rs:163-206) must support setting/clearing scheduling fields alongside title/description/priority updates.
• REQ-10: Hydration (hydration.rs:240-252) must pass scheduling fields from IssueFile through HydratedIssue into SQLite.

Acceptance Criteria

• AC-1: crosslink create "title" --scheduled 2026-03-20 --due 2026-03-25 creates an issue with scheduled_at stored as 2026-03-20T00:00:00Z and due_at as 2026-03-25T23:59:59Z. (REQ-2, REQ-6)
• AC-2: crosslink quick "title" -p high --due 2026-03-25 creates an issue with due date set and scheduled_at as None. (REQ-2, REQ-6)
• AC-3: crosslink update <id> --scheduled 2026-03-20 sets scheduled_at without changing due_at. (REQ-2, REQ-9)
• AC-4: crosslink update <id> --no-due clears due_at. --due X and --no-due simultaneously is rejected by clap. (REQ-3)
• AC-5: crosslink show <id> on an issue with both dates prints Scheduled: 2026-03-20 and Due: 2026-03-25. (REQ-5)
• AC-6: crosslink show <id> on an issue with no scheduling dates does not print Scheduled/Due lines. (REQ-5, REQ-8)
• AC-7: crosslink next with an issue whose scheduled_at is tomorrow excludes it. (REQ-4)
• AC-8: crosslink next with a medium overdue issue and medium non-overdue issue ranks the overdue one higher (score 300 vs 200). (REQ-4)
• AC-9: crosslink next with an issue due in 6 hours prints Due in 6 hours alongside the recommendation. (REQ-4)
• AC-10: Scheduling dates survive a full round-trip: create -> SQLite -> show — dates match. (REQ-1, REQ-10)
• AC-11: Deserializing an existing Issue JSON without scheduling fields succeeds with both defaulting to None. (REQ-8)
• AC-12: crosslink create "subtask" --parent 1 --due 2026-03-25 is rejected with error. (REQ-7)
• AC-13: crosslink next with no-date issues includes them (dateless issues always eligible). (REQ-4, REQ-8)
• AC-14: crosslink create "title" --due 2026-03-20T14:00:00Z stores exactly 2026-03-20T14:00:00Z, not adjusted. (REQ-6)
• AC-15: Schema migration v15->v16 adds scheduled_at TEXT and due_at TEXT columns to issues table. (REQ-1)

Architecture

Data Model Changes (Layer 1-4)

All four issue representations gain the same two optional fields with #[serde(default, skip_serializing_if = "Option::is_none")]:

• Issue struct in crosslink/src/models.rs:5-15 — add after closed_at
• IssueFile in crosslink/src/issue_file.rs:13-45 — add after closed_at (line 29)
• CompactIssue in crosslink/src/checkpoint.rs:63-87 — add after closed_at (line 78)
• HydratedIssue in crosslink/src/db/hydration.rs:8-20 — add scheduled_at: Option<&'a str> and due_at: Option<&'a str> after closed_at

Database Schema (Layer 5)

Increment SCHEMA_VERSION from 15 to 16 in crosslink/src/db/core.rs:5. Add migration:

ALTER TABLE issues ADD COLUMN scheduled_at TEXT;
ALTER TABLE issues ADD COLUMN due_at TEXT;

Update insert_hydrated_issue in crosslink/src/db/hydration.rs:55-62 to include the two new columns in the INSERT statement.

Update create_issue_with_parent in crosslink/src/db/issues.rs:33-62 to accept and insert optional scheduling params.

Update get_issue / row parsing in crosslink/src/db/issues.rs:98-105 to read the two new columns.

Update update_issue in crosslink/src/db/issues.rs:189-243 to accept optional scheduling params and include them in the SET clause.

Hydration (Layer 6)

In crosslink/src/hydration.rs, the hydration loop (around line 240) constructs HydratedIssue from IssueFile. Add:

let scheduled_at = issue.scheduled_at.map(|dt| dt.to_rfc3339());
let due_at = issue.due_at.map(|dt| dt.to_rfc3339());

Pass scheduled_at.as_deref() and due_at.as_deref() to the HydratedIssue.

SharedWriter (Layer 7)

create_issue in crosslink/src/shared_writer/mutations.rs:18-86: Add optional scheduled_at: Option<DateTime<Utc>> and due_at: Option<DateTime<Utc>> parameters. Set on the IssueFile struct (line 38-56).

create_subissue in crosslink/src/shared_writer/mutations.rs:91-160: No changes — subissues don't support scheduling (REQ-7).

update_issue in crosslink/src/shared_writer/mutations.rs:163-206: Add optional scheduling params. The existing pattern does direct file mutation (no events), so scheduling follows the same approach: read issue file, merge fields, write back, push.

CLI (Layer 8)

Add to Create and Quick structs in crosslink/src/main.rs:

#[arg(long, value_parser = parse_scheduled_date)]
scheduled: Option<DateTime<Utc>>,
#[arg(long, value_parser = parse_due_date)]
due: Option<DateTime<Utc>>,

Add to Update struct:

#[arg(long, value_parser = parse_scheduled_date)]
scheduled: Option<DateTime<Utc>>,
#[arg(long, conflicts_with = "scheduled")]
no_scheduled: bool,
#[arg(long, value_parser = parse_due_date)]
due: Option<DateTime<Utc>>,
#[arg(long, conflicts_with = "due")]
no_due: bool,

Two parser functions in a shared location (e.g. crosslink/src/utils.rs or inline in main.rs):

• parse_scheduled_date: YYYY-MM-DD -> T00:00:00Z, or parse as RFC 3339
• parse_due_date: YYYY-MM-DD -> T23:59:59Z, or parse as RFC 3339

Commands (Layer 9)

commands/create.rs (crosslink/src/commands/create.rs:115-197): Validate REQ-7 (reject --parent + scheduling). Pass scheduling params through to SharedWriter::create_issue or db.create_issue_with_parent. Warn if scheduled > due.

commands/update.rs (crosslink/src/commands/update.rs:8-39): Extend "at least one field required" check at line 16. Compute new scheduling state (set/clear/unchanged) and pass to SharedWriter::update_issue.

commands/show.rs (crosslink/src/commands/show.rs): After the Updated: line, print:

Scheduled: 2026-03-20
Due:       2026-03-25

Only when set. Format as %Y-%m-%d.

commands/next.rs (crosslink/src/commands/next.rs:49-157):

1. After lock filter (line 77): skip if scheduled_at > now
2. In scoring (line 88): add +100 if due_at < now (overdue)
3. In output (line 114-135): print Due in X hours/days if due_at within 1 day

Test Updates

Every test that constructs an Issue struct directly (models.rs tests, prop tests, various command tests) needs scheduled_at: None, due_at: None added. A grep -r "Issue {" --include="*.rs" will find all sites. The #[serde(default)] annotation handles deserialization backward compat automatically.

New unit tests needed:

• Date parser tests (YYYY-MM-DD vs RFC 3339, start-of-day vs end-of-day)
• next.rs scoring with scheduling (overdue boost, future filter, deadline warning)
• Show formatting with/without dates
• Create + update with scheduling params
• Schema migration v16

Open Questions

Q1: Event emission for scheduling changes — RESOLVED

Decision: Option A — direct file mutation, no event. Consistent with existing update_issue pattern for title/description/priority. Git history on the hub branch provides the audit trail. Event emission can be added later as a separate enhancement for all update types.

Out of Scope

• Filtering issue list by scheduled/due dates
• Recurring / repeating schedule patterns
• Timezone-aware scheduling (all dates are UTC)
• Calendar integration or external notifications
• Relative date input (+3d, tomorrow)
• Subissue-level scheduling dates (inherited from parent via next lookup)
• Event emission for scheduling changes (deferred per Q1 unless team decides otherwise)