At least one non-founder produces a cycle plan via pm-agent chat

### Summary -- What & Why

Non-founder users may not know how to ask the pm-agent for a complete cycle plan. Add a clearly labeled cycle-planning template that lowers the friction for starting the flow and orients the user toward producing an Objective, at least one KR, and two or more work issues. Without an easy starter template, non-founders are less likely to attempt a full plan, reducing chances of hitting the success criterion.

### Acceptance Criteria (pre-merge)

- [ ] The chat UI includes a visible 'Create cycle plan' template in the template list
- [ ] Selecting the template opens a pre-filled planner flow and displays a preview of the generated plan before submission
- [ ] Automated tests show the template is selectable and results in a plan-preview being produced

### Acceptance Criteria (post-merge)


### Prerequisites for Autonomous Execution

### Summary -- What & Why

Sessions currently end without guaranteeing the user produced an Objective + KR + ≥2 work issues. Add a lightweight, user-facing checklist shown before a session can be marked complete that explicitly calls out the three completion criteria and blocks completion until they appear in the generated plan. This raises the probability that completed sessions meet the measurement triple required for the KR.

### Acceptance Criteria (pre-merge)

- [ ] A visible checklist is present in the end-of-session UI that lists: Objective, ≥1 KR, and ≥2 work issues
- [ ] Attempting to mark the session complete when any checklist item is missing shows a blocking prompt and prevents completion
- [ ] When the checklist is satisfied, the UI allows completion and shows a completion confirmation to the user

### Acceptance Criteria (post-merge)


### Prerequisites for Autonomous Execution

### Summary -- What & Why

The KR measurement depends on completion events containing user attribution and the agent-run identifier. If those properties are missing or malformed, the smoke-test cannot link sessions to created Objectives/KRs/work issues. Ensure completion events consistently include a non-founder user identifier and the run id used to tag created issues, and add an automated nightly verification that checks event shape and presence.

### Acceptance Criteria (pre-merge)

- [ ] Session completion events emitted by the pm-agent include both a user distinct identifier and a run identifier property in every test event
- [ ] Unit or integration tests validate the event payload contains the two required properties and fail if they are absent

### Acceptance Criteria (post-merge)

- [ ] Nightly job queries the analytics API for recent pm-agent completion events and asserts that returned events contain a user distinct identifier and the run identifier property

### Prerequisites for Autonomous Execution

### Summary -- What & Why

Real non-founder traffic is required in the cycle window for any measurement to succeed. Prepare a small, targeted outreach plan with recipient selection, messaging variants, tracking links, and calendar scheduling so humans can quickly send invites during the cycle window. Without timely outreach, there may be zero non-founder sessions in the measurement window.

### Acceptance Criteria (pre-merge)

- [ ] A documented target-segmentation doc is added describing recipient criteria and a short list of candidate non-founder recipients
- [ ] Ready-to-send email drafts and two short social/DM copy variants are created and stored in the repo and as drafts in the email-draft system
- [ ] A short experiment plan (A/B variants, success signals, and send schedule) and calendar event drafts exist to coordinate sends

### Acceptance Criteria (post-merge)


### Prerequisites for Autonomous Execution

- Human to send the prepared emails/DMs and/or post to social channels
- Access to the team social accounts or DM channels to actually perform outreach

### Summary -- What & Why

We cannot reliably know if non-founders can complete a full cycle plan because manual testing is brittle and production traffic is noisy. A deterministic e2e harness that simulates a non-founder session and verifies the creation of an Objective, a KR, and at least two work issues (all tagged with the same RUN_ID across the two target projects) will give us reproducible confidence that the flow works and increase the chance of passing the cycle-8 smoke test. Without this harness, we risk shipping regressions that break the measurable success criterion.

### Acceptance Criteria (pre-merge)

- [ ] A runnable e2e script is added that simulates a pm-agent session producing a complete plan when invoked with a test RUN_ID. Verification command: node ./scripts/e2e/pm-agent-complete-plan.js --run-id E2E-TEST-1 (script must exit 0)
- [ ] After running the script, verify an Objective or KR was created in the goals repo containing the RUN_ID. Verification command: gh search issues --query "E2E-TEST-1 repo:gonzalomelov/goals" --json totalCount | jq '.totalCount'
- [ ] After running the script, verify at least two work issues were created in the birthdayinvites.app repo containing the RUN_ID. Verification command: gh search issues --query "E2E-TEST-1 repo:gonzalomelov/birthdayinvites.app" --json totalCount | jq '.totalCount'

### Acceptance Criteria (post-merge)


### Prerequisites for Autonomous Execution

### Summary -- What & Why

Non-founders often drop out before the agent produces the full plan triple. A concise, visible in-chat checklist that the agent uses to confirm completion (exposed behind a feature flag for controlled rollout) will increase completion rates. Adding automated tests that exercise the checklist path will ensure the agent enforces creation of Objective + KR + ≥2 work issues for flagged users. If we don't add this, observed non-founder completion may remain below the success threshold and the project could be paused.

### Acceptance Criteria (pre-merge)

- [ ] A Playwright e2e test is added that opens a pm-agent session with the checklist feature enabled and asserts the session results in an Objective, a KR, and at least two work issues sharing the same RUN_ID. Verification command: npx playwright test tests/pm-agent/checklist-e2e.spec.ts --reporter=list (exit 0)
- [ ] Static check that the repository contains the public checklist copy used by the agent (so copy review can happen in PR). Verification command: grep -n "Complete your cycle plan" -R || true

### Acceptance Criteria (post-merge)

- [ ] Nightly verification runs the checklist e2e and exits 0: npx playwright test tests/pm-agent/checklist-e2e.spec.ts --reporter=list (this command must be included in the nightly job to validate post-merge behaviour)

### Prerequisites for Autonomous Execution