Summary

pm get <id> does not surface schedule fields (events[]/start_at/end_at/location/all_day/timezone/recurrence) for Meeting, Event, and Reminder items, even though pm meet/pm event/pm remind write them, the on-disk TOON record stores them, and pm context agenda returns them.

Impact

Any human or coding agent using the canonical pm get <id> (or pm get <id> --json) to inspect a scheduled item sees no time information at all — the meeting/event looks like a timeless stub. This breaks the agent read loop: a tool that creates a meeting with pm meet --start +1h then reads it back with pm get cannot recover when/where it is. Users must know to also call pm context and correlate by item_id, which is non-obvious. Calendar/scheduling workflows are effectively unreadable through get.

Environment

• pm version: 2026.7.4 (@unbrained/pm-cli, global)
• Node version: v22.20.0
• npm version: 11.18.0
• OS: Linux pop-os 7.0.9-76070009-generic x86_64 (Ubuntu 22.04 base)
• Shell: bash
• Install method: npm install -g @unbrained/pm-cli
• Project state: fresh tracker (pm init --defaults), no packages required to reproduce

Area

CLI (output projection for get on scheduled item types)

Reproduction

From a clean folder:

export PM_AUTHOR=repro PM_PATH="$(mktemp -d)/.pm"
pm init --defaults --agent-guidance skip
# 1. create a meeting scheduled +1h for 1h; note the events[] in the output
pm meet "Sync" --start +1h --duration 1h --json
# 2. read it back with the canonical get command
pm get <id-from-step-1> --json

Step 1 output includes:

"events": [ { "start_at": "...", "end_at": "..." } ]

Step 2 output has no events, start_at, end_at, location, or any schedule field — only id/title/description/type/status/priority/tags/created_at/updated_at/author/parent/body.

The data is on disk (<tracker>/meetings/<id>.toon contains events[1]{start_at,end_at}: "...") and is returned by pm context --json under agenda.events[] (at, event_end, event_location, event_all_day, …).

Expected

pm get returns the same schedule fields it stores — at minimum events[] with start_at/end_at, plus location/all_day/timezone/recurrence_rule when present. The get projection should not silently drop a first-class typed field that create returns and that has a dedicated agenda renderer.

Actual

pm get omits the entire schedule. Confirmed in both default TOON and --json output.

Evidence

• repro directory: repros/get-omits-schedule-fields/ (repro.sh, expected.txt, actual.txt)
• key excerpt — create returns events, get does not:
  • pm meet … --json → "events": [{"start_at":"2026-07-05T16:09:37.363Z","end_at":"2026-07-05T17:09:37.363Z"}]
  • pm get … --json → item object ends at "body": "" with no events block
• on-disk record confirms persistence: events[1]{start_at,end_at}: "2026-07-05T16:09:37.363Z","2026-07-05T17:09:37.363Z"
• pm context --json confirms readability elsewhere: agenda.events[].at / .event_end / .event_location

Duplicate search performed

(to be run before submit; logged here)

• gh issue list -R unbraind/pm-cli --state all --search "get schedule events" --limit 20
• gh issue list -R unbraind/pm-cli --state all --search "meeting start_at get" --limit 20
• gh search issues "pm get events start_at repo:unbraind/pm-cli" --state all

Workaround

Use pm context --json and read agenda.events[] filtered by item_id, or read the on-disk <tracker>/<type-plural>/<id>.toon file directly. Both are non-obvious and bypass the canonical get.

Proposed improvement

Include the events[] (schedule) field — and the related location/all_day/timezone/recurrence_rule fields — in the pm get item projection for Meeting/Event/Reminder types, matching the create response and on-disk schema. If projection is intentionally minimal, add a --fields/--with-schedule selector and document it; but the default for scheduled types should show scheduling.

Dogfood context

Found while building the ContextOps dogfood project and creating realistic Meeting/Event/Reminder items (Phase 3 / Phase 10 scheduling). Created a meeting with pm meet --start +1h --duration 1h, then immediately did pm get to verify and noticed the schedule had "vanished" from the read view. Reproduced in a clean isolated tracker (PM_PATH=$(mktemp -d)/.pm).