Print: entitle the sandbox, and stop the ⌘P chord from ever falling through

Root cause of the owner's repro (board window frontmost, File ▸ Print…
enabled, chosen from the menu, alert appears anyway): Kanban.entitlements
carried no com.apple.security.print key. The app is sandboxed, and a
sandboxed NSPrintOperation is denied by the sandbox with exactly this
wording — "This application does not support printing. Please contact
the application's developer." — regardless of which code path invokes
it. Fix: add the entitlement.

Alongside it, hardening for a separate, narrower failure mode that
happens to produce the identical alert text by a different mechanism:
PrintCommand used to disable itself over a window that published
neither a board nor a printable card (welcome, the template chooser,
Settings, the restore-bootstrap window, a card window whose board
hasn't joined). A disabled SwiftUI Button still owns its
.keyboardShortcut, so the unclaimed ⌘P chord fell through to AppKit's
own nil-target printDocument: action, whose stock failure is the same
system alert. The row now claims ⌘P unconditionally in every window;
scope resolves at the moment of the action instead (board, then card,
then a polite "Nothing to Print" / "Open a board or a card to print
it." refusal in the app's own voice). The boolean isEnabled(hasBoard:
hasPrintableCard:) becomes a three-way PrintCommand.resolveScope(...)
-> Scope pure function.

Also implements AppDelegate's application(_:printFiles:withSettings:
showPrintPanels:) — Finder's own File ▸ Print… / drag-to-printer /
print-and-open path was previously unhandled, its own separate route
to the same stock alert. PrintCoordinator.printFiles loads each path
headless through BoardLoader (no store, no window) and either prints
it or gives the same one-sentence refusal; the operation-building code
shared with the in-app path is factored out of run(_:) into
makeOperation(for:showsPrintPanel:) and runOperation(_:session:).

Docs: 11-command-nexus.md's Print row, PrintCommand's and
PrintCoordinator's doc comments, KanbanApp.swift's CommandGroup
comment, and project.yml's entitlements comment all narrate the
entitlement as the actual fix and the scope work as hardening beside
it.

Tests: PrintCommandValidationTests now exercises resolveScope's three
arms in place of the old boolean. A new PrintFinderResolutionTests
suite covers PrintCoordinator.resolveFinderPrint(atPath:) — the one
piece of the Finder half a test can drive without handing AppKit a
real print job — against a real board, an empty non-board folder, a
plain file, and an unsupported schema.

Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy
This commit is contained in:
2026-08-08 23:46:16 -04:00
parent ce92c24190
commit 9e6f4567df
7 changed files with 432 additions and 76 deletions
+9
View File
@@ -320,6 +320,15 @@ struct KanbanApp: App {
// window*, which no responder vends. Two items sharing the title "Print" is also exactly what
// titles-are-API forbids.
//
// A reported "This application does not support printing" alert (2026-08-09) turned out to be
// the sandbox denying `NSPrintOperation` for want of `com.apple.security.print`
// (`Kanban.entitlements`) the actual fix, not anything here. Found alongside it, and worth
// keeping regardless: `PrintCommand` used to disable itself over a window with no board and no
// card, and a disabled `Button` still owns its `.keyboardShortcut` the unclaimed chord fell
// straight through to AppKit's own nil-target `printDocument:`, whose stock failure happens to be
// the identical alert text by a different route. The row now claims P unconditionally and
// answers the no-board-no-card case itself (`PrintCommand`'s doc comment).
//
// Page Setup stays absent with it: the paper questions are answered in the print panel's own
// page-setup group (`PrintCoordinator`), so a second dialog would be a second place to set one
// margin.