Bug: Audit log missing duration_ms for request_next_task — no perform…

[treble37]

Pull Request

PyCon 2026 Sprint contributor? Welcome! Fill this out and a maintainer will review within the sprint day.

Description

This PR closes the remaining gaps in the request_next_task audit logging work for issue #228. It adds regression tests first, then fixes the two missing behaviors: audit entries now record task_count=0 when the board is empty instead of omitting the field, and the FastMCP/HTTP request_next_task path now routes through the same audited handler used by the stdio server so duration_ms and task_count are captured consistently across transports.

What does this PR do?

It adds regression coverage for request_next_task audit behavior, fixes audit task counting so empty boards log task_count=0, and routes FastMCP request_next_task calls through handle_tool_call so HTTP/FastMCP requests use the same audit wrapper as stdio.

Why is this change needed?

Before this change, the acceptance criteria for #228 were only partially met: task_count was dropped when the board was empty, and the FastMCP/HTTP request_next_task path bypassed the audit wrapper entirely. That meant duration_ms and task-count telemetry were not reliably recorded on all supported request paths.

Related Issue(s):

Fixes #(issue number)

• Added regression tests covering request_next_task audit logging for task_count=0 on both success and access-denied paths.
• Added a regression test proving FastMCP request_next_task delegates through handle_tool_call instead of calling the tool implementation directly.
• Updated audit task-count handling to preserve 0 for empty boards and routed FastMCP/HTTP request_next_task through the audited handler path.

---

📸 Proof: Marcus ran on my machine

Replace this line with your screenshot or terminal output.

---

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• ♻️ Code refactoring (no functional changes)
• ⚡ Performance improvement
• 🧪 Test updates or additions
• 🔧 Configuration/build changes

Branch Information

• This PR targets the develop branch (not main)
• My branch is up-to-date with upstream/develop
• I'm working in my fork's feature branch
• I've synced with upstream to avoid conflicts

Changes Made

Testing

Unit Tests:

• All existing tests pass (pytest)
• I have added tests for my changes
• Test coverage is ≥80% for new code

Integration Tests:

• Integration tests pass (if applicable)
• I have tested with external services (Planka/GitHub/etc.) if applicable

Manual Testing:

Describe what manual testing you performed:

Test Environment:

• OS: [e.g., macOS 13, Ubuntu 22.04]
• Python Version: [e.g., 3.11.5]
• Running via: [Docker / Local Python]

Code Quality

• All pre-commit hooks pass (pre-commit run --all-files)
• MyPy type checking passes (mypy src/)
• Code is formatted with Black (black src/)
• Imports are organized with isort (isort src/)
• Ruff linting passes (ruff check src/)
• No secrets detected (detect-secrets scan)
• My code follows the project's style guidelines

Documentation

• I have updated relevant documentation in docs/
• I have added NumPy-style docstrings to new functions/classes
• I have updated CHANGELOG.md (if user-facing change)
• Code comments explain complex logic or decisions
• README.md updated (if needed)

Privacy / Telemetry

• Every field listed in docs/telemetry.md § What we collect
  has a writer in the codebase that actually populates it by
  the time this PR merges (no "we collect this" promises
  without code that ships the data).
• Every field NOT in docs/telemetry.md § What we collect
  is verifiably not shipped (no code paths add it to a
  telemetry event).
• Any print / sys.stdout.write added to a telemetry code
  path is justified — Marcus's MCP stdio mode reserves stdout
  for JSON-RPC, and any non-protocol bytes corrupt the channel.
  Default: write to stderr or a log file.
• If a new event type, new field, or new dimension is added,
  docs/telemetry.md is updated in the same PR.

Documentation Changes:

Backwards Compatibility

• This change maintains backwards compatibility
• This change includes breaking changes (described below)
• This change follows the deprecation process (if applicable)

Breaking Changes (if any):

Migration Guide (if needed):

Screenshots / Demos

Before:

After:

Performance Impact

• No performance impact
• Performance improved
• Potential performance impact (described below)

Performance Notes:

Dependencies

• No new dependencies added
• New dependencies added (listed below)

New Dependencies:

Checklist

• I have read the CONTRIBUTING.md guide
• My code follows the project's code style
• I have performed a self-review of my code
• I have commented complex code, particularly hard-to-understand areas
• I have made corresponding changes to documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Additional Notes

Reviewer Focus Areas:

Open Questions:

Post-Merge Actions

• Update deployment documentation
• Notify users of breaking changes
• Update related issues
• Other: ___________

---

For Maintainers

• Code review completed
• All CI checks pass
• Documentation is adequate
• Breaking changes properly communicated
• Ready to merge to develop