feat(backlog): daily/refine comment context, interactive standup posting, and filter parity

.cursor/rules/automatic-openspec-workflow.mdc

@@ -186,7 +186,7 @@ When user requests a change, **do not write or modify any application code yet**
    - Confirm with user: "OpenSpec change ready. Proceed with implementation?"
 
 2. **If user confirms or if workflow requires immediate application:**
-   - Execute: `/opsx:apply <change-id>` (or `/specfact-cli/wf-apply-change <change-id>`)
+   - Execute: `/opsx:apply <change-id>`
    - Follow workflow steps:
      - Change selection
      - Read change artifacts
@@ -235,7 +235,7 @@ AI (automatically):
    - Creates change proposal, spec deltas, tasks
    - Validates: openspec validate <id> --strict
 5. Verifies: Shows change summary; "Proceed with implementation?"
-6. Applies: /opsx:apply <change-id> (or /wf-apply-change <change-id>)
+6. Applies: /opsx:apply <change-id>
    - Implements the change (TDD: tests first, then code)
    - Updates tasks
 7. After implementation: Verify (quality gates), validate (openspec validate), sync backlog

CHANGELOG.md

@@ -9,6 +9,29 @@ All notable changes to this project will be documented in this file.
 
 ---
 
+## [0.30.2] - 2026-02-11
+
+### Fixed (0.30.2)
+
+- **Backlog daily/refine filter parity and selection semantics**
+  - Added missing global filter flags to `specfact backlog daily`: `--search`, `--release`, `--id` (parity with refine).
+  - Fixed daily issue-window semantics so `--first-issues`/`--last-issues` are applied over the full filtered candidate set (not pre-truncated by default limit).
+  - Added assignee column in daily standup tables and fixed GitHub `--assignee me`/`@me` handling to use provider semantics without incorrect literal local post-filtering.
+- **Interactive comment UX**
+  - `specfact backlog daily --interactive` now renders comments in scoped panel blocks (refine-like) for clearer context.
+  - Interactive default remains latest-comment-first; explicit `--first-comments`/`--last-comments` now controls the displayed comment window and shows omitted-count hints.
+  - Interactive navigation now supports **Post standup update** on the currently selected story; successful post feedback includes explicit story ID and URL.
+- **GitHub adapter contract binding bug**
+  - Fixed icontract decorator placement in `GitHubAdapter` so interactive standup comment posting no longer fails with contract-argument binding errors (`item`/`update_fields`) when checking comment capability.
+- **Docs and prompt updates**
+  - Updated daily/refine docs and prompt templates with standardized filter parity guidance (`--search`, `--release`, `--id`, `--first-issues`, `--last-issues`) and clarified comment behavior (interactive latest-only vs export/summarize full context by default).
+
+### Changed (0.30.2)
+
+- **Version**: Bumped to `0.30.2` (patch).
+
+---
+
 ## [0.30.1] - 2026-02-10
 
 ### Fixed (0.30.1)

CLAUDE.md

@@ -84,25 +84,84 @@ Use `from specfact_cli.common import get_bridge_logger` — never `print()`. Deb
 - `bugfix/your-bugfix-name`
 - `hotfix/your-hotfix-name`
 
-### Post-Change Checklist
+### Pre-Commit Checklist
 
-1. `hatch run format`
-2. `hatch run type-check`
-3. `hatch run contract-test`
-4. `hatch test --cover -v`
+Run all steps in order before committing. Every step must pass with no errors.
+
+1. `hatch run format`                # ruff format + autofix
+2. `hatch run type-check`            # basedpyright strict
+3. `hatch run lint`                  # full lint suite
+4. `hatch run yaml-lint`             # YAML + markdown validation
+5. `hatch run contract-test`         # contract-first validation
+6. `hatch run smart-test`            # targeted test run (use `smart-test-full` for larger modifications)
 
 ### OpenSpec Workflow
 
-Before modifying application code, check if an OpenSpec change exists in `openspec/`. This is the spec-driven workflow defined in `openspec/config.yaml`. Skip only when explicitly told ("skip openspec", "direct implementation", "simple fix").
+Before modifying application code, **always** verify that an active OpenSpec change in `openspec/changes/` **explicitly covers the requested modification**. This is the spec-driven workflow defined in `openspec/config.yaml`. Skip only when the user explicitly says `"skip openspec"` or `"implement without openspec change"`.
+
+**Claude MUST NOT apply any code edits** when a fix, change, modification, or edit to any codebase file is requested unless an active OpenSpec change exists that explicitly covers the requested scope. If no such change exists, ask for clarification:
+
+- **a) New change** — create a new OpenSpec change proposal (`/opsx:new`)
+- **b) Modify existing** — select and continue an existing change in `openspec/changes/`
+- **c) Delta** — add a targeted delta to an existing change's specs
+
+The existence of *any* open change is not sufficient — the change must specifically address the requested modification. Do not proceed until one of the above is resolved.
+
+#### Change Order (`openspec/CHANGE_ORDER.md`)
+
+`openspec/CHANGE_ORDER.md` is the **single source of truth** for change sequencing, module grouping, and inter-change dependencies. Always use it to avoid redundant analysis of `openspec/changes/` folders.
+
+**Read it first** — before creating, implementing, or archiving any change, consult `CHANGE_ORDER.md` to:
+- Check which changes are already archived (implemented) and their dates
+- Verify hard blockers are resolved before starting implementation
+- Understand where a new change fits in module order and wave sequencing
+
+**Keep it updated** — whenever a change lifecycle event occurs, update `CHANGE_ORDER.md` in the same commit:
+- **New change created**: add a row to the correct module group table with folder name, GitHub issue link, and blocked-by dependencies
+- **Change archived**: move the entry from "Pending" to "Implemented (archived)" with the archive date; update wave status if a wave is now complete
+- **Change modified/renamed**: update the folder name and any affected dependency references
+- **Blocker resolved**: update the "Blocked by" column (append ✅ to resolved blockers)
 
 ### Version Updates
 
 When bumping version, sync across: `pyproject.toml`, `setup.py`, `src/specfact_cli/__init__.py`. CI/CD auto-publishes to PyPI on merge to `main` only if version exceeds the published one.
 
+**Version semantics (SemVer):**
+- `feature/*` branches → **minor** increment (e.g. `0.5.0 → 0.6.0`)
+- `bugfix/*` / `hotfix/*` branches → **patch** increment (e.g. `0.5.0 → 0.5.1`)
+- Breaking changes or major milestones → **major** increment (requires explicit confirmation)
+
+Always propose the increment type based on the branch name and ask for confirmation before applying the bump.
+
+### Changelog
+
+Keep `CHANGELOG.md` updated with every meaningful change. Update it in the same commit that bumps the version — never let them diverge.
+
+- Follow [Keep a Changelog](https://keepachangelog.com/) format: `Added`, `Changed`, `Fixed`, `Removed`, `Security`
+- Each version entry must match the version in `pyproject.toml`
+- Unreleased changes accumulate under `## [Unreleased]` until a version bump
+
 ### Commits
 
 Follow Conventional Commits: `feat:`, `fix:`, `docs:`, `test:`, `refactor:`.
 
+### Documentation
+
+Keep docs current with every code change that affects user-facing behaviour.
+
+- Docs source lives in `docs/` and is published to [docs.specfact.io](https://docs.specfact.io) via GitHub Pages (Jekyll)
+- **Preserve all front-matter** on every edit (`title`, `layout`, `nav_order`, `permalink`, etc.) — check `docs/_layouts/default.html` and `docs/index.md` before adding or removing front-matter keys
+- When a command, option, or behaviour changes, update the corresponding doc page in the same PR
+- Broken or outdated docs for users are P0 — prefer a small doc fix over shipping undocumented changes
+
+### README Maintenance
+
+`README.md` (repo root) and the docs landing page (`docs/index.md` or `docs/README.md`) must stay in sync with what SpecFact actually does.
+
+- On larger refactorings or feature additions, reconsider the README from an **external / new-user perspective**: lead with value and USP, not internal architecture
+- A first-time reader should understand what SpecFact does, why they'd use it, and how to get started within the first screen
+- Do not let the README drift from the actual CLI interface or command list
+
 ## Code Conventions
 
 - Python 3.11+, line length 120, Google-style docstrings

docs/getting-started/tutorial-daily-standup-sprint-review.md

@@ -19,15 +19,15 @@ This tutorial walks you through a complete **daily standup and sprint review** w
 - Run **`specfact backlog daily`** and see your standup table (assigned + unassigned items) with **auto-detected** GitHub org/repo or Azure DevOps org/project from the git remote
 - Use **`.specfact/backlog.yaml`** or environment variables when you're not in the repo (e.g. CI) or to override
 - **Post a standup comment** to the first (or selected) item with `--yesterday`, `--today`, `--blockers` and `--post`
-- Use **`--interactive`** for step-by-step story review (arrow-key selection, full detail, **existing comments on each issue** when the adapter supports them)
+- Use **`--interactive`** for step-by-step story review (arrow-key selection, full detail, latest comment + hidden-count hint, and optional in-flow posting on the selected story)
 - Use **`--copilot-export <path>`** to write a Markdown summary for Copilot slash-command during standup;
   add **`--comments`** (alias **`--annotations`**) to include descriptions and comment annotations when
   the adapter supports fetching comments
 - Use **`--summarize`** or **`--summarize-to <path>`** to output a **prompt** (instruction + filter context
   + standup data) for a slash command (e.g. `specfact.daily`) or copy-paste to Copilot to **generate a
   standup summary**; add **`--comments`**/**`--annotations`** to include comment annotations in the prompt
 - Use the **`specfact.backlog-daily`** (or `specfact.daily`) slash prompt for interactive walkthrough with the DevOps team story-by-story (focus, issues, open questions, discussion notes as comments)
-- Filter by **`--assignee`**, **`--sprint`** / **`--iteration`**, **`--blockers-first`**, and optional **`--suggest-next`**
+- Filter by **`--assignee`**, **`--sprint`** / **`--iteration`**, **`--search`**, **`--release`**, **`--id`**, **`--first-issues`** / **`--last-issues`**, **`--blockers-first`**, and optional **`--suggest-next`**
 
 ---
 
@@ -88,7 +88,7 @@ Default scope is **state=open**, **limit=20**; overridable via `SPECFACT_STANDUP
 
 ## Step 3: Post a Standup Comment (Optional)
 
-To add a **standup comment** to the **first** item in the list (e.g. the one you're working on), pass **values** for yesterday/today/blockers and `--post`:
+To add a **standup comment** to the **first** item in the list, pass **values** for yesterday/today/blockers and `--post`:
 
 ```bash
 specfact backlog daily github \
@@ -98,7 +98,7 @@ specfact backlog daily github \
   --post
 ```
 
-**Expected**: The CLI posts a comment on that item's issue (GitHub issue or ADO work item) with a standup block (Yesterday / Today / Blockers). You'll see: `✓ Standup comment posted to <issue URL>`.
+**Expected**: The CLI posts a comment on that item's issue (GitHub issue or ADO work item) with a standup block (Yesterday / Today / Blockers). You'll see: `✓ Standup comment posted to story <id>: <issue URL>`.
 
 **Important**: You must pass **values** for at least one of `--yesterday`, `--today`, or `--blockers`. Using `--post` alone (or with flags but no text) will prompt you to add values; see the in-command message and help.
 
@@ -113,8 +113,8 @@ specfact backlog daily github --interactive
 ```
 
 - Use the menu to **select** an item (arrow keys).
-- View **full detail** (description, acceptance criteria, standup fields, and **existing comments annotated to that issue** when the adapter supports fetching comments—e.g. GitHub issue comments, ADO work item discussion).
-- Choose **Next story**, **Previous story**, **Back to list**, or **Exit**.
+- View **full detail** (description, acceptance criteria, standup fields, and comment context). Interactive detail shows the **latest comment only** plus a hint when older comments exist.
+- Choose **Next story**, **Previous story**, **Post standup update** (posts to the currently selected story), **Back to list**, or **Exit**.
 
 Use **`--suggest-next`** to show a suggested next item by value score (business value / (story points × priority)) when the data is available.
 
@@ -183,7 +183,7 @@ issues/open questions, discussion notes as comments).
 4. **Optional: interactive review** or **Copilot export**:
 
    ```bash
-   specfact backlog daily github --interactive
+   specfact backlog daily github --interactive --last-comments 3
    # or
    specfact backlog daily github --copilot-export ./standup.md
    ```
@@ -197,7 +197,8 @@ issues/open questions, discussion notes as comments).
 | View standup without typing org/repo | Run `specfact backlog daily github` or `ado` from **repo root**; org/repo or org/project are **auto-detected** from git remote. |
 | Override or use outside repo | Use `.specfact/backlog.yaml`, env vars (`SPECFACT_GITHUB_REPO_OWNER`, etc.), or CLI `--repo-owner`/`--repo-name` or `--ado-org`/`--ado-project`. |
 | Post standup to first item | Use `--yesterday "..."` `--today "..."` `--blockers "..."` and `--post` (values required). |
-| Step through stories with full detail (including issue comments) | Use `--interactive`; optionally `--suggest-next`. |
+| Post standup while reviewing selected story | Use `--interactive` and choose **Post standup update** from navigation. |
+| Step through stories with readable comment context | Use `--interactive`; it shows latest comment + hidden-count hint. Use `--first-comments`/`--last-comments` to tune comment density. |
 | Feed standup into Copilot | Use `--copilot-export <path>`; add `--comments`/`--annotations` for comment annotations. |
 | Generate standup summary via AI (slash command or Copilot) | Use `--summarize` (stdout) or `--summarize-to <path>`; add `--comments`/`--annotations` for comment annotations; use with `specfact.backlog-daily` slash prompt. |
 

docs/guides/agile-scrum-workflows.md

@@ -26,12 +26,17 @@ SpecFact CLI supports real-world agile/scrum practices through:
   (yesterday/today/blockers) from item body; optionally post standup comment to linked issue via `--post`
   when the adapter supports comments (e.g. GitHub).
   **Interactive step-by-step review**: Use `--interactive` to select stories with arrow keys (questionary)
-  and view full detail (refine-like: description, acceptance criteria, standup fields, comments when adapter
-  supports); navigate with Next/Previous/Back to list/Exit. Use `--suggest-next` to show suggested next
-  item by value score (business_value / (story_points × priority)).
+  and view full detail (refine-like: description, acceptance criteria, standup fields). Interactive detail
+  shows the **latest comment only** plus a hint when older comments exist; use export options for full
+  comment history. Navigate with Next/Previous/**Post standup update**/Back to list/Exit. `Post standup update`
+  posts yesterday/today/blockers to the currently selected story (adapter support required). Use `--suggest-next`
+  to show suggested next item by value score (business_value / (story_points × priority)).
   **Copilot export**: Use `--copilot-export <path>` to write a summarized Markdown file of each story for
   Copilot. Add `--comments` (alias `--annotations`) to include descriptions and comment annotations in
-  `--copilot-export` and `--summarize` outputs when the adapter supports `get_comments` (GitHub).
+  `--copilot-export` and `--summarize` outputs when the adapter supports `get_comments` (GitHub, ADO). Use
+  `--first-comments N` or `--last-comments N` to scope comment volume when needed (default: include all).
+  Use `--first-issues N` or `--last-issues N` (mutually exclusive) to scope daily output to oldest/newest
+  items by numeric issue/work-item ID.
   **Kanban**: omit iteration/sprint and use state + limit; unassigned = pullable work. **Scrum/SAFe**: use
   `--sprint current` and optional priority/value. **Out of scope**: Sprint goal is in your board/sprint
   settings (not displayed by CLI). Stale/at-risk flags (e.g. "no update in N days") are not in scope—use
@@ -76,9 +81,9 @@ specfact backlog daily github \
   --post
 
 # 4. Optional: interactive step-through, Copilot export, or standup summary prompt
-specfact backlog daily github --interactive   # step-through; detail view shows existing comments on each issue
+specfact backlog daily github --interactive   # step-through; detail view shows latest comment + hidden-count hint
 # or
-specfact backlog daily github --copilot-export ./standup.md --comments
+specfact backlog daily github --copilot-export ./standup.md --comments --last-comments 5
 # or
 specfact backlog daily github --summarize --comments     # prompt to stdout for AI to generate standup summary
 specfact backlog daily github --summarize-to ./standup-prompt.md
@@ -88,7 +93,9 @@ Use the **`specfact.backlog-daily`** (or `specfact.daily`) slash prompt for inte
 DevOps team story-by-story (current focus, issues/open questions, discussion notes as comments). Default
 scope: **state=open**, **limit=20**; configure via `SPECFACT_STANDUP_*` or `.specfact/standup.yaml`. Use
 `--assignee me`, `--sprint current`, `--blockers-first`, `--interactive`, `--suggest-next`,
-`--copilot-export <path>`, `--summarize`, `--summarize-to <path>`, and `--comments`/`--annotations` as
+`--copilot-export <path>`, `--summarize`, `--summarize-to <path>`, `--comments`/`--annotations`, and optional
+`--first-comments`/`--last-comments` plus `--first-issues`/`--last-issues` as well as global filters
+`--search`, `--release`, and `--id` to narrow scope consistently with backlog refine
 needed. See [Tutorial: Daily Standup and Sprint Review](../getting-started/tutorial-daily-standup-sprint-review.md)
 for the full walkthrough.