hermes - 💡(How to fix) Fix Pre-existing `ty` type errors in hermes_cli/kanban_db.py (4 diagnostics) [3 pull requests]

Summary

ty (the repo's pinned type checker, ty==0.0.21) reports 4 pre-existing type errors in hermes_cli/kanban_db.py on main. They are unrelated to any single feature and predate recent kanban work; filing them so they can be tracked and fixed independently.

I surfaced these while verifying that PR #35869 (fix(kanban): set journal_mode=WAL once per process) introduced no new type diagnostics. It does not — these 4 exist on main untouched by that PR. Filing separately to keep that PR scoped to the WAL fix per the "only changes related to this fix" checklist item.

Environment

• Checker: ty==0.0.21 (as pinned in pyproject.toml [dependency-groups].dev)
• Config: [tool.ty.environment] python-version = "3.13"
• Command: ty check --output-format concise hermes_cli/kanban_db.py

The 4 diagnostics

Line numbers are against current main. Each is also pinned to its enclosing function so they stay locatable as the file drifts.

1. invalid-parameter-default — _record_task_failure

hermes_cli/kanban_db.py:4999:5: error[invalid-parameter-default]
Default value of type `None` is not assignable to annotated parameter type `int`

def _record_task_failure(
    ...
    failure_limit: int = None,   # <- None default under an `int` annotation
    ...
):

Root cause / fix: the annotation should admit None. Change to failure_limit: int | None = None (and narrow at use sites, or substitute a concrete default where one is intended).

2. invalid-parameter-default — _record_spawn_failure

hermes_cli/kanban_db.py:5154:5: error[invalid-parameter-default]
Default value of type `None` is not assignable to annotated parameter type `int`

def _record_spawn_failure(
    ...
    failure_limit: int = None,   # same pattern as #1
    ...
):

Fix: same as #1 — failure_limit: int | None = None.

3. invalid-argument-type — detect_crashed_workers calling _record_task_failure

hermes_cli/kanban_db.py:4978:17: error[invalid-argument-type]
Argument to function `_record_task_failure` is incorrect:
Expected `int`, found `Literal[1] | None`

_record_task_failure(
    ...
    failure_limit=1 if (protocol_violation or is_systemic) else None,
    ...
)

Note: this is a downstream consequence of #1. The call site deliberately passes int | None; it only type-errors because _record_task_failure's parameter is annotated int. Fixing #1 resolves this one automatically.

4. unsupported-operator — task_age

hermes_cli/kanban_db.py:6381:9: error[unsupported-operator]
Operator `-` is not supported between objects of type `int` and `int | None`

def task_age(task: Task) -> dict:
    ...
    _co - (_s or _c) if _co is not None else None

Root cause: _s or _c is int | None (both operands can be None), so the subtraction can hit int - None. The _co is not None guard narrows _co but not the right operand. Fix: ensure the right operand is narrowed to int before subtracting (e.g. compute _start = _s if _s is not None else _c with an explicit int fallback, or guard both).

Grouping / suggested approach

• #1 + #3 are one fix (correct the _record_task_failure annotation; the call site then type-checks).
• #2 is the same one-line annotation fix on _record_spawn_failure.
• #4 is independent (operand narrowing in task_age).

All four are annotation/narrowing fixes with no behavior change. Happy to open a focused PR if useful — let me know whether you'd prefer one PR for all four or split by function.

Why this matters

ty runs as an advisory (non-blocking) check today, but #4 in particular (int - None) reflects a real latent TypeError path if task_age is reached with both timestamps unset. The _record_* annotations are misleading to callers about whether None is accepted.