Bug: Power-steering stop hook incorrectly activates on Q&A/PM/Operations sessions (e.g. /pm-architect)

[rysweet]

Bug Description

The power-steering stop hook (power_steering_checker.py) incorrectly classifies Q&A and PM/Operations sessions (e.g., those initiated via /pm-architect) as INVESTIGATION and applies development-focused checks that are irrelevant to these session types.

Affected Session Types

• /pm-architect sessions (pure project management prioritization)
• /qa sessions (Q&A, informational queries)
• Any session focused on backlog triage, roadmap planning, sprint prioritization

Reproduction Steps

1. Start a new session with /pm-architect prompt
2. Agent reads backlogs, issues, and roadmap files (multiple Read/Grep operations, no Write/Edit of code files)
3. Agent provides PM analysis/recommendations and attempts to stop
4. Power-steering hook fires at stop time

Expected behavior: Hook detects PM/Operations session type and skips or reduces irrelevant development checks.

Actual behavior: Hook classifies session as INVESTIGATION (because many Read/Grep without Write/Edit = investigation indicator). Applies the following irrelevant checks:

• workflow_invocation — Was a development workflow invoked? (irrelevant: PM sessions don't need dev workflows)
• next_steps — Were all next steps completed? (false positive: PM sessions naturally produce prioritization lists as output, not incomplete tasks)
• documentation_updates — Were docs updated to reflect code changes? (irrelevant: no code was changed)

Root Cause

In detect_session_type() in power_steering_checker.py:

# INVESTIGATION: Tool-based heuristics (Read/Grep without modifications)
# Catches investigation sessions that don't have explicit keywords
if self._has_investigation_indicators(read_grep_operations, write_edit_operations):
    self._log("Session classified as INVESTIGATION via tool usage patterns", "INFO")
    return "INVESTIGATION"

The _has_investigation_indicators heuristic (read_grep_operations >= 2 and write_edit_operations == 0) correctly identifies investigation sessions but cannot distinguish them from PM/Operations sessions, which also involve reading many files without writing code.

There is no session type for PM/Operations/Planning sessions. The existing types are: SIMPLE, DEVELOPMENT, INFORMATIONAL, MAINTENANCE, INVESTIGATION.

Proposed Fix

1. Add an OPERATIONS session type for PM, planning, backlog triage, and operations tasks.
2. Add PM-specific keyword detection in detect_session_type() (keywords: prioritize, backlog, roadmap, sprint, triage, pm-architect, project management, etc.).
3. Check for OPERATIONS keywords before the investigation tool-usage fallback.
4. Update considerations.yaml so that workflow_invocation, next_steps, and documentation_updates do not apply to OPERATIONS sessions.
5. Add test coverage in test_power_steering_checker.py to verify PM sessions are classified as OPERATIONS.

Impact

• False positive blocking loops during PM sessions
• Repeated irrelevant prompts blocking legitimate PM work
• No workaround without setting AMPLIHACK_SESSION_TYPE=INFORMATIONAL env var

Related

• This is similar to fixes for SIMPLE sessions (#see SIMPLE_TASK_KEYWORDS) and INFORMATIONAL detection
• The existing _is_qa_session() method has a limit of tool_uses >= 2 that causes PM sessions with many Read operations to not qualify as Q&A