task-work: recognize app.notion.com URLs (closes #158)

[martin-conur]

Problem

Starting a worker for a Notion task silently dropped the spec URL: the worker launched with a bare /worker and no task, and the operator had to paste the URL in by hand. Jira was unaffected.

Root cause (#158)

is_notion_url() only matched notion.so / notion.site:

is_notion_url() { [[ "$1" == *"notion.so"* || "$1" == *"notion.site"* ]]; }

Notion now serves workspace/page links as app.notion.com — and the Notion MCP fetch/search tools return URLs in that form. The predicate returned false, no arg-resolution branch matched, and parsing fell through to the slug-only else, leaving NOTION_URL="". build_claude_cmd then emitted claude … "/worker" with no task identifier. Deterministic, not flaky.

Fix

Add notion.com to the predicate in both Notion loadouts (claude-notion, kiro-notion):

is_notion_url() {
  [[ "$1" == *"notion.so"* || "$1" == *"notion.site"* || "$1" == *"notion.com"* ]]
}

Safe: real notion.so/notion.site URLs never contain notion.com, nor does a free-form slug. derive_slug_from_url already handles the …/p/<32-hex> tail.

Tests

Added regression tests (confirmed red before the fix, green after) for the single-arg and explicit slug + URL forms using an app.notion.com URL:

• tests/claude_notion_task_work.bats (3)
• tests/kiro_task_work.bats (2)

Full suite: 799 passing, 0 failures; drift check passes; shellcheck clean on both edited scripts.

Note

#158 speculated task-reviewer carries the same predicate — it does not. Its non-gh path uses a generic SPEC_IDENTIFIER="$ISSUE_INPUT" with no Notion-specific filter, so it was never affected. No change needed there.

Closes #158

🤖 Generated with Claude Code

[martin-conur]

Closing as a duplicate of #161. Both PRs fix #158 with the same notion.com predicate change across both notion loadouts; #161 has a reviewer sign-off (clean-with-nits) and is getting the anchored-regex hardening applied. Consolidating there. Thanks for this one — the analysis here was spot-on.