[michielbdejong]

Closes #1741

What

A plugin's manifest destination can now declare keyed tables beside (or instead of) its single table. Set up creates each table beneath the plugin, with its own row class and a default view. Each kind of record gets its own table, so statements never show up as rows of the transactions table.

"destination": {
  "schema": { "properties": [...], "classes": [...] },
  "table": { "name": "Bank transactions", "rowClass": "bank-transaction", "columns": ["bank-amount"] },
  "tables": {
    "statements": { "name": "Bank statements", "rowClass": "bank-statement", "columns": ["statement-number"] },
    "closingBalances": { "name": "Closing balances", "rowClass": "closing-balance", "columns": ["balance-date", "bank-amount"] }
  }
}

The stored config (under config.key) is { table, rowClass, properties, tables: { statements: { table, rowClass }, closingBalances: { table, rowClass } } }. The importer writes a statement with parent: config.tables.statements.table. A drive app shown as a view of any of these tables gets the same map from await store.getData(), as { table, rowClass, tables }.

The money app needs this for stored statements and closing balances (ontola/atomic-plugins#148, M-7 and M-12). Once this lands, money can keep table for transactions, add tables, and add tables to config.required. Existing installations then show Set up once more, and it creates only the new tables.

Rules (the same in TS and Rust, same messages)

• Declare table, tables or both. tables must not be empty.
• A key starts with a lower-case letter and has only letters and digits, at most 64 characters. Names of Object.prototype members (constructor, ...) are refused.
• Each table needs its own rowClass, and it must be a class declared in schema. Columns must be declared properties.

Unchanged for single-table manifests

• Same config { table, rowClass, properties }, same table localId (atomic:destination:table), so existing installs resume the same table.
• The release id is unchanged, because destination is still carried verbatim. destination_fixtures_keep_their_release_ids pins the single-table fixture's id, which matches release-ids.json on claude/atomic-plugins-pin.
• App package content is unchanged: the stored bytes of a package carrying the single-table manifest are pinned by sha-256 in app-package.test.ts.

Base

The destination Set up step (#1653, branch claude/plugin-accepts-file) is on develop (via #1699) and on the atomic-plugins pin branches, but not on claude/installation-connect. So this branch is claude/installation-connect plus a merge of claude/plugin-accepts-file (2 commits). The conflicts in plugin-manifest.ts, index.json and en.po were resolved by keeping both sides. That merge is the first commit. The change itself is the second.

Changes

• browser/lib/src/plugin-manifest.ts: DeclaredDestinationTable, destination.tables and their validation.
• browser/lib/src/plugin-destination.ts (new): provisionDestination moved here from FileImport.tsx and extended to cover tables. Also adds destinationTablesFor.
• server/src/plugins/manifest.rs: validate_destination mirrors the TS checks. Before this, the server only required destination to be a map.
• hostStore.ts: the data op adds tables when the table belongs to a multi-table destination.
• FileImport.tsx: when there is more than one table, Set up lists them.
• docs/src/plugins/creating-plugins.md: documents accepts and destinations with one table or several.
• browser/lib/src/test-schema-store.ts: the fake store from plugin-app.test.ts, now shared.

Tests

• Shared fixtures in testdata/plugin-manifest/ (2 accepted, 11 rejected), run by both plugin-manifest.test.ts and shared_manifest_conformance.
• plugin-destination.test.ts:
  • single-table config unchanged
  • multi-class Set up creates every table with its own class and view
  • keyed tables with no primary table
  • Set up resumes, and a later release that adds a table creates only that one
  • destinationTablesFor from any of the tables, with or without a config key, and nothing for a single-table destination
• hostStore.test.ts: data returns tables for a multi-table destination and the old shape otherwise.
• app-package.test.ts: package content is pinned. A multi-table release is carried, and an invalid one is refused.
• destination_fixtures_keep_their_release_ids (Rust).
• Runs: browser/lib vitest (998 passed), data-browser AppPage/PluginRuns/AppSetup vitest (45 passed), pnpm typecheck, cargo test -p atomic-server --lib (288 passed), clippy clean on manifest.rs.
• Checked by hand against a running server: Set up created the 3 tables, and handleRequest(…'data'…) on the transactions table and on the statements table both returned the keyed tables.

Translations

The catalogs were settled with one vite run after rm -rf src/locales/.wuchale. The diff has one new message ("Set up creates {0} tables for this importer. Nothing is imported yet.") and a changed placeholder comment on the single-table message.

Screenshots

Set up for a three-table importer, before and after, on desktop (1280) and mobile (390). They were taken with Playwright against the running app and shared in the session:
multiclass-desktop-before.png, multiclass-desktop-after.png, multiclass-mobile-before.png, multiclass-mobile-after.png.

🤖 Generated with Claude Code

[michielbdejong]

Merge-risk triage (2026-09-28). This is a read-only review of this PR's own diff. The rule it applies: nothing that works today may break for existing users or clients, and new behaviour is added alongside the old. The stack is being rebased onto develop as one chain before merging, so line references are against the current stacked base.

Verdict: SAFE-WITH-FIX

The client side is additive (data only adds tables), and single-table config and release ids are pinned.

Fix before merging: The new server-side validate_destination is much stricter than develop's "a map" check, and it runs inside Manifest::parse, which runs on every read of a stored release (plugin_sync.rs, plugin_external.rs, actions.rs). A release already stored with a looser destination (e.g. published through the CLI or API) would stop parsing, and runs and sync for its existing install would break. Validate on publish/ingest only, not when parsing stored releases.

Note: It carries a merge of claude/plugin-accepts-file (#1653), whose content is already on develop via #1699. Those hunks should disappear after the rebase.

🤖 Generated with Claude Code

[michielbdejong]

Replaced by the consolidated #2148 (Q-101), which carries this change onto develop. The branch is kept. Closed by Claude (VPS coordinator) on behalf of Michiel.