Intervals Time Entry

These files persist between sessions. Seed them from this repo's templates on first install, then treat them as shared runtime state for both Claude and Codex.

Mandatory Safety Gates

These rules are not optional:

1. Preview before filling — Before any Intervals form is filled, show the proposed entries to the user as a table with: Project | Module (if any) | Work Type | Hours | Description and include the total hours.
2. Tweak loop required — If the user wants changes, revise the proposed entries, show the updated table again, and wait. Do not fill until the user is satisfied.
3. Explicit go-ahead required — Only run the fill script after the user explicitly confirms they want you to proceed (for example: “go ahead”, “fill them in”, or equivalent).
4. Fill only, never submit — Never click Intervals Save/Submit buttons or trigger any final submission action yourself. Filling the rows is allowed; submitting the timesheet is always the user's manual step.
5. Hand control back after fill — After the rows are filled, take a screenshot, point out that the form is ready for review, and tell the user to submit manually if everything looks right.

Workflow

Phase 1: Read Notes

Read the daily note for the requested date. Default location: Daily Notes/YYYY-MM-DD.md

Look for:

• Time entries with project/work descriptions
• Links to GitHub PRs or repos (e.g., https://github.com/owner/repo/pull/123)
• Mentions of PR numbers (e.g., "PR #123", "reviewed PR 456")

Phase 1.5: GitHub Activity Correlation (REQUIRED)

ALWAYS run this phase to fetch GitHub activity and enhance time entry descriptions.

Step 1: Fetch Activity

Run this command (replace YYYY-MM-DD with the target date):

bash scripts/fetch-github-activity.sh YYYY-MM-DD

This returns JSON with:

• PRs authored (created or updated)
• PRs reviewed
• Events with timestamps (commits, reviews, comments)

IMPORTANT: The script output already includes PR titles and body snippets in prs_authored, prs_active, and prs_reviewed. Do NOT make separate gh pr view calls — use the data already returned by the script.

Step 2: Correlate with Notes

Using the JSON output from Step 1:

1. Match PRs to time entries: If notes mention a PR or repo, link it to that entry
2. Infer repo→project mappings: When a PR clearly matches a time entry's project, add to .cache/om/intervals-cache/github-mappings.md
3. Extract PR links from notes: Look for GitHub URLs and extract repo/PR info

Step 4: Enhance Descriptions

ALWAYS improve descriptions when GitHub data provides more context. The goal is to make time entries self-documenting and meaningful for future reference.

Before/After Examples:

Rules:

• Use the PR title as the primary description when available (it's usually well-written)
• Use the PR description/body for additional context when the title alone is too brief or generic
• Add PR number in parentheses at the end: (PR #123)
• For reviews, briefly describe each PR reviewed (2-5 words each)
• For commits without PRs, summarize the commit messages
• Keep to 1-2 sentences max, but make them specific and meaningful
• Never use generic descriptions like "development work" when GitHub has specifics

Step 5: Suggest Adjustments

Compare GitHub activity to notes and flag potential issues:

Missing time entries: If GitHub shows significant activity (multiple commits, PRs) for a repo but notes have no corresponding entry, suggest adding one.

Time discrepancies: Use commit timestamps to estimate minimum time spent:

• Calculate span from first to last commit on a repo
• Account for gaps >2h as breaks
• If notes show significantly less time than commits suggest, flag for review

Example output:

⚠️ GitHub shows commits on technomic-api from 9:15am to 3:30pm (~4-5h with breaks)
   but notes only show 2h for Technomic dev work. Consider adjusting.

💡 Found PR #456 "Fix payment edge case" for Technomic - using for description.

📝 No time entry found for 3 PR reviews on ewg-frontend. Suggest adding:
   - EWG: 0.5-1h Architecture/Technical Design (PR reviews #12, #13, #14)

Phase 1.7: Outlook Calendar Correlation (REQUIRED)

ALWAYS run this phase to visually read the Outlook calendar and cross-reference with notes and GitHub activity.

Prerequisite: User must be logged into Outlook Web in the browser (same Chrome instance with --remote-debugging-port=9222).

Step 1: Find or Open Outlook Web Tab

IMPORTANT: Never navigate away from the user's current tab. Always find an existing Outlook tab or create a new one.

1. Call list_pages to see all open browser tabs
2. Look for a tab with URL containing outlook.office.com or outlook.live.com
3. If found: call select_page with that page's ID
4. If NOT found: call new_page with the day view URL (see Step 2)

Step 2: Navigate, Verify, and Extract Calendar Data

Navigate to the target date's day view: