feat(kanban): distinguish task artifacts from attachments

[frizikk]

What does this PR do?

Fixes #83960.

Kanban task files currently share one storage table and one UI list, even though files supplied to a task and files generated by its worker have different lifecycle meaning. This change adds a backward-compatible attachment_type discriminator and carries it through storage, REST, CLI, model tools, worker context, and the dashboard.

The column is nullable by design: existing rows and older writers that omit it continue to behave as input attachments. Completion outputs and files added by Kanban worker tools are recorded as artifacts by default. The dashboard and worker prompt render the two categories separately while preserving the existing authenticated download/delete and path-containment mechanisms.

Related Issue

Fixes #83960

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• hermes_cli/kanban_db.py
  • Adds an idempotent nullable attachment_type migration with constrained attachment/artifact values.
  • Treats legacy NULL rows as attachments at read time.
  • Marks collected task-completion outputs as artifacts.
• hermes_cli/kanban.py, tools/kanban_tools.py
  • Expose file type in list/create flows; worker-produced files default to artifacts.
  • Validate the requested type before writing a file.
• plugins/kanban/dashboard/plugin_api.py, plugins/kanban/dashboard/dist/index.js
  • Serialize the type and render separate Attachments and Artifacts sections.
• Tests cover migration compatibility, legacy rows, DB/REST/CLI/tool round trips, completion collection, worker context grouping, and real bundled dashboard rendering.

How to Test

.venv/bin/python -m pytest \
  tests/plugins/test_kanban_attachments.py \
  tests/hermes_cli/test_kanban_db.py \
  tests/tools/test_kanban_tools.py \
  -q -o 'addopts='
# 73 passed, 1 skipped

npm --workspace web exec -- vitest run src/lib/kanban-task-files-plugin.test.ts
# 1 passed

npm --workspace web run typecheck
npm --workspace web run build
npm --workspace web exec -- eslint src/lib/kanban-task-files-plugin.test.ts

.venv/bin/ruff check \
  hermes_cli/kanban.py hermes_cli/kanban_db.py \
  plugins/kanban/dashboard/plugin_api.py \
  tests/hermes_cli/test_kanban_db.py \
  tests/plugins/test_kanban_attachments.py \
  tests/tools/test_kanban_tools.py tools/kanban_tools.py
node --check plugins/kanban/dashboard/dist/index.js
git diff --check

Mutation evidence: changing the artifact classifier to classify attachments instead made the new Vitest regression fail; restoring the implementation returned it to green.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this feature
• I've run the relevant focused automated checks listed above
• I've added tests for my changes
• I've tested on my platform: CachyOS Linux, Python 3.11, Node.js 25

Documentation & Housekeeping

• Documentation update — N/A; the existing Kanban attachment commands/tools now report the file role directly
• cli-config.yaml.example update — N/A; no config key was added
• CONTRIBUTING.md / AGENTS.md update — N/A; no workflow or architecture policy changed
• Cross-platform impact considered — schema and path handling remain platform-neutral; existing authenticated file transport is reused
• Tool descriptions/schemas updated — existing Kanban attachment tool descriptions now state that worker outputs are artifacts

For New Skills

N/A — this PR does not add a skill.

Screenshots / Logs

No screenshot: the change is covered by a behavioral test that executes the registered Kanban dashboard bundle and asserts separate Attachments/Artifacts groups. Focused Python, Vitest, typecheck, build, Ruff, ESLint, Node syntax, and diff checks all passed. The repository-wide Python suite was not run.

[enzo-adami]

Independent validation on current origin/main (165c889) and combined with #86610 artifact confinement (95a2f8bbf6a096ea156cb18268760ae08d172440): the backend patches compose correctly. The confined completion copy is recorded as attachment_type=artifact; legacy/manual uploads remain attachment. The combined repository-runner suite passed 121 tests, 0 failed (1 Windows-only skip), covering attachment migration/API/worker context, completion behavior, confinement, notifications, and watchers; git diff --check is clean.

One integration item remains: this branch conflicts with current main in plugins/kanban/dashboard/dist/index.js. I excluded only that conflicted bundled file from the current-main backend reconstruction, so this is not a claim that the UI bundle is rebased. Please regenerate/reconcile that bundle on fresh main and rerun web/src/lib/kanban-task-files-plugin.test.ts. The Python/backend contract is compatible with #86610.

[enzo-adami]

Follow-up with a fully reconstructed dependency stack (not just a backend patch simulation):

• main@165c889e5b4277b56dadd42949a4112c1e6175a6
• then fix(kanban): confine completion artifacts to task workspace #86610 as its three unchanged commits (2aebcce863, 6c9c7d6a71, ab93d6bf7d)
• then your exact fbebd05fce9d4a873425d457e6af11b841942f2e change, preserving author metadata as d620cd9905f591ac062acd99d6b5997157261e4a

The only conflict is still plugins/kanban/dashboard/dist/index.js. Important correction to my earlier wording: the file header says Plain IIFE, no build step; it is the maintained plugin source/entry, not a regenerable generated artifact. I resolved it at source level by retaining current main’s requestDialog destructive-confirmation path and parameterizing it for both attachment and artifact rows. The real registered bundle test passes.

Reproducible handoff branch/commit: enzo-adami@d620cd9

Validation on the combined stack:

• focused Python cluster: 95 passed, 1 Windows-only skip
• web/src/lib/kanban-task-files-plugin.test.ts: 1 passed
• Node syntax: PASS
• Ruff: PASS
• changed-production Windows footgun scan: PASS
• diff check from main: PASS

I also tried to find a classification-specific confinement bypass. I did not find one: attachment_type is presentation/metadata only; completion paths still pass _scope_completion_artifacts and #86610 staging, notifier delivery independently requires the pinned per-task attachment root, and invalid upload classifications are rejected before a blob is created. Existing adversarial tests for outside-workspace sources, source symlink swap, destination-root symlink, and unstaged notifier paths remain green in this stack. I therefore did not open a duplicate extension PR.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

feat(kanban): distinguish task artifacts from attachments

1. hermes_cli/kanban_db.py: the attachment_type CHECK constraint string is duplicated between CREATE TABLE task_attachments and the _add_column_if_missing migration. A future type addition requires editing both in lockstep. Since VALID_ATTACHMENT_TYPES already centralizes the allowed values, generating the CHECK from that constant (or a shared _ATTACHMENT_TYPE_CHECK_SQL) would remove the drift risk.

2. Default classification differs by surface: the CLI attach --type defaults to attachment, the dashboard upload Form defaults to attachment, but the agent tools kanban_attach/kanban_attach_url default to artifact. The tool schema documents its default, but the same "add a file" action labels the file differently depending on who performed it. Aligning defaults (or documenting the per-surface rationale in one place) would reduce surprise.

3. plugins/kanban/dashboard/dist/index.js (TaskFilesSection): artifact rows get a "Remove artifact" button with a destructive confirm identical to attachments. Artifacts are worker-generated outputs that later workers may rely on, and deletion has no undo. Minor UX note: consider making artifact deletion require a stronger confirmation, or note in the UI that removing an artifact cannot be undone.

No blocking issues found.

[frizikk]

Rebased onto current main (7095e23e) and refreshed the Kanban artifact implementation in 00284b42645b1de5285387cc9805262a4a0c88b9.

• integrated the current attachment/storage APIs and UI contracts
• verified focused Python and Desktop attachment suites, typecheck, ESLint, Ruff, Windows-footgun scan, and git diff --check
• independent exact-SHA Spec and Standards reviews: PASS

The PR is now rebased, mergeable, and has no unresolved review threads. Fresh CI is running.