Which owner emits bundle declarations (Info.plist CFBundleURLTypes, .desktop, MSIX) for protocol-client and login-item registration? #393

Activity

1. 0monish

   added the

   Task

   issue type on Oct 6, 2026
2. 0monish

   added

   wayfinder:taskWayfinder prerequisite taskWayfinder prerequisite task

   electron-compatElectron compatibility program areaElectron compatibility program area

   on Oct 6, 2026
3. 0monish

   added a parent issue on Oct 6, 2026

   • Wayfinder map: KELD Electron Compatibility Program (Electron 44.x baseline) #391
4. 0monish commented on Oct 6, 2026

   

   0monish

   on Oct 6, 2026

   MemberAuthor

   More actions

   Generated by an AI agent (Claude Code, Fable 5.1) on behalf of @0monish, 2026-10-06, under the map's execution doctrine. Statements are labelled FACT / INFERENCE / UNKNOWN by their author; nothing here authorizes implementation.

   Decision packet

   Decision: Protocol-client and login-item registration stay 'returns false with a diagnostic' (F01-T6 (#454)) and the bundle-declaration emitter is parked; when it is un-parked, keld-pack emits the declarations under the owner-designated KEL-19 packaging track, behind a new approved spec.

   Classification: decided · Milestone (YAGNI test against the first proof): parked · Reversible: Yes. Parking changes no code or contract, and F01-T6 (#454) already returns false with a diagnostic. · Owner: Crate keld-pack, tracked on KEL-19 by owner direction (status Done as an RFC, live packaging comments through 2026-10-06; Linear fetched 2026-10-06). KEL-89 (In Progress, unassigned) consumes the deeplink rung. KEL-15 (Done) holds the ratified config-file contract. No live Linear issue owns a bundle-declaration emitter.

   Facts

   • FACT: Neither draw.io nor Zettlr calls setAsDefaultProtocolClient, isDefaultProtocolClient, setLoginItemSettings or getLoginItemSettings, and neither listens for open-url. Source: grep of corpus/drawio-desktop/src and corpus/zettlr/source, 0 hits, 2026-10-06.
   • FACT: The first-proof workflow is install + activation + open, edit, save, close-with-unsaved-prompt. Source: panel/synthesis.md line 64.
   • FACT: Electron says 'On macOS, you can only register protocols that have been added to your app's info.plist, which cannot be modified at runtime'. Source: Electron v44.4.5 docs/api/app.md, setAsDefaultProtocolClient, verified by both F01 refuters against the pinned file; pinned copy re-fetched 2026-10-06.
   • FACT: The ticket's premise 'keld-pack is a name-only enum' is stale. At main b4b907c keld-pack owns the Windows v0 package producer and the ExpectedAppIdentity container writer and readers. It has no Info.plist, .desktop or MSIX emitter (grep of crates/keld-pack/src and crates/keld-cli/src: 0 hits). Source: /crates/keld-pack/src/lib.rs header.
   • FACT: Architecture 01 section 5 names keld-pack as the future shipper of the .app ('the .app launch once keld-pack ships one; until then the spawn of the staged keld-host'). Source: /docs/architecture/01-overview.md line 215.
   • FACT: KEL-19 has status Done (completed 2026-07-10 as the CLI RFC), yet the owner directed that packaging work 'be tracked on this existing issue rather than a new one'. Its live tasks are the Windows identity container: T1 landed (feat(pack): ExpectedAppIdentity host container writer and readers (KEL-19 T1) #386), T2 passed on real Windows, T3 gated on the release channel (GitHub release: define and prove the first honest dev-preview release #181). No bundle-declaration task exists. Source: Linear KEL-19 comments c3dded99, 4a472696, 048e5f56, fetched 2026-10-06.
   • FACT: KEL-15 has status Done (2026-07-10). Its only comment ratifies exactly four config files: keld.config.ts holds app identity and windows, keld.build.ts holds 'targets, signing, update feed, delta settings', generated by migrate from the electron-builder config. Source: Linear KEL-15 comment d1137b07, fetched 2026-10-06; docs/architecture/04-electron-compat.md section 2.
   • FACT: keld-native lists deeplink and autostart as module names only; keld-auth records 'no .app bundle/plist emitter exists' for its custom-scheme rung. Source: crates/keld-native/src/lib.rs MODULES; docs/specs/keld-auth.md lines 534-551. KEL-89 is In Progress, unassigned (Linear, fetched 2026-10-06).
   • FACT: F01-T6 (task(app): facade-local shims with honest diagnostics — commandLine store, enableSandbox, disableHardwareAcceleration, protocol-client and login-item false-with-diagnostic, and L0 typed-unsupported rows (parked) #454) (task(app): facade-local shims with honest diagnostics — commandLine store, enableSandbox, disableHardwareAcceleration, protocol-client and login-item false-with-diagnostic, and L0 typed-unsupported rows (parked) #454) names 'Linear owner consumed: KEL-72'; KEL-72 has status Done, unassigned. Source: publish_plan.json; Linear KEL-72, fetched 2026-10-06.

   Inferences

   • INFERENCE: With zero call sites in both corpus apps, neither the first proof nor the Zettlr follow-up needs a real registration, so designing the config fields now would be speculative.
   • INFERENCE: The ticket assumes the fields go in keld.config.ts, but the ratified file contract puts electron-builder-derived packaging input in keld.build.ts. A scheme is needed both by the packager and by the host at run time, so the field's home is a real one-source-of-truth question for the later spec.
   • INFERENCE: The runtime grant can reuse keld-guard's exact-match scope branch (keld-auth precedent) without a new matcher. Taken from the refuter verdict; not re-verified in this session.

   Unknowns

   • UNKNOWN: Which config file owns the declared schemes and autostart flag (keld.config.ts or keld.build.ts) and how the value reaches the host without a second source.
   • UNKNOWN: The mapping of SMAppService status to Electron's four login-item status strings (no Apple receipt gathered).
   • UNKNOWN: Whether Linux autostart is offered at all (Electron tags login items macOS and Windows only).
   • UNKNOWN: Which Linear issue will track the macOS .app bundle emitter. KEL-141 (Backlog, unassigned) covers distribution of the Keld CLI and host, not app bundle declarations.

   Alternatives

   Option	Cost	New invariant created	Existing invariant at risk
   Park: keep F01-T6 (#454) honest-false; decide owner and fields only when a committed corpus app calls these APIs	Apps that register a scheme get false plus a diagnostic until the emitter exists.	Registration never reports success without a materialised OS declaration.	None.
   Specify the emitter and config fields now	A permission-model, wire-protocol and config-schema spec for behaviour no current corpus app uses, plus an Info.plist/.desktop/MSIX emitter that does not exist on any OS.	New grant groups for deeplink registration and autostart, and new config fields.	YAGNI; the four-file config contract; one source of truth for a value needed by both packager and host.
   Register at run time from the Bun role	Impossible on macOS per Electron's own documentation; forbidden by KEL-78 zero ambient authority under strict.	None.	Zero ambient OS authority for strict roles; default-deny.

   Recommendation

   Park it. Correct the ticket text (keld-pack is no longer name-only; the emitter is what is missing). Point F01-T6 (#454)'s diagnostic at this ticket rather than KEL-72. Re-open only when a committed corpus app has a resolved call site, and then write one spec under the KEL-19 packaging track that settles the config file question first.

   Falsifier: A resolved call site of setAsDefaultProtocolClient, setLoginItemSettings or an open-url listener in a committed corpus app, or an owner statement that the first proof's 'activation' cell includes launch by URL scheme.

   Missing evidence: None needed for the park. For the later spec: the config-file home of the declaration, the SMAppService status receipt, and a named tracker for the macOS bundle emitter.

   Next action: Owner: the map orchestrator. Mark #393 parked with the corrected keld-pack fact and the re-open trigger, and fix the owner line on #454. First check: #454's diagnostic text names #393 and no longer cites KEL-72 as a live owner. Discovered here, not solved here: draw.io declares CFBundleDocumentTypes file associations in its electron-builder config (electron-builder-linux-mac.json), which would use the same absent emitter; route that to F01-T5 (#453) (#453) only if the activation cell includes opening a file from Finder.
5. 0monish

   added

   milestone:parkedParked by the YAGNI test until a current requirement proves itParked by the YAGNI test until a current requirement proves it

   on Oct 6, 2026
6. 0monish commented on Oct 6, 2026

   

   0monish

   on Oct 6, 2026

   MemberAuthor

   More actions

   Generated by an AI agent (Claude Code, Fable 5.1) on behalf of @0monish, 2026-10-06, under the map's execution doctrine. Statements are labelled FACT / INFERENCE / UNKNOWN by their author; nothing here authorizes implementation.

   Resolution

   Park it. Correct the ticket text (keld-pack is no longer name-only; the emitter is what is missing). Point F01-T6 (#454)'s diagnostic at this ticket rather than KEL-72. Re-open only when a committed corpus app has a resolved call site, and then write one spec under the KEL-19 packaging track that settles the config file question first.

   Falsifier (reopen if observed): A resolved call site of setAsDefaultProtocolClient, setLoginItemSettings or an open-url listener in a committed corpus app, or an owner statement that the first proof's 'activation' cell includes launch by URL scheme.

   Resolved under the user's delegation on the evidence in the decision packet above, after independent refutation of the underlying research. Reopen by comment with contrary primary evidence.
7. 0monish

   closed this as completedon Oct 6, 2026