summercms/.planning/quick/261004-rou-move-user-api-tokens-from-fonoteka-plugi/261004-rou-PLAN.md

phase, plan, type, wave, depends_on, autonomous, requirements, files_modified

phase	plan	type	wave	depends_on	autonomous	requirements	files_modified
quick-261004-rou	01	execute	1		true	QUICK-261004-rou	../fonoteka.go/plugins/golem15/user/** ../fonoteka.go/plugins/golem15/fonoteka/** ../fonoteka.go/config/** ../fonoteka.go/parity/** ../sm-bm-app/plugins/golem15/user ../sm-bm-app/plugins/jz/bm/** ../sm-bm-app/plugins/jz/bm .planning/STATE.md .planning/quick/261004-rou-move-user-api-tokens-from-fonoteka-plugi/**

Quick 261004-rou: Move User API Tokens to sm-user-plugin

Objective

Make golem15.user the single owner of personal API-token persistence, minting, authentication, scope checks, management commands/routes, and user permission grants. Fonoteka and BM must consume the same token credential so one token can reach multiple plugin APIs, with each plugin still enforcing its own domain access and the authenticated user's group permissions.

Existing Fonoteka inv_ tokens, OAuth links, MCP route names, response shapes, collection pins, and PHP parity must remain valid. The uncommitted BM management-API work is preserved, but its plugin-local bm_ table, model, guard, and token commands are replaced rather than committed as a second token system.

Tasks

Task 1: Add shared API-token ownership to sm-user-plugin

• Add the user_api_tokens model and migration, token manager/guard, shared user.api_token middleware, user.scope:<scope> factory, generic token management routes and user:token:* commands.
• Load user-group permission JSON into bouncer.Principal.PermissionGrants for both JWT and API-token authentication, and cover grant parsing/authentication/scope/management behavior with tests.
• Keep token secrets one-time-only and SHA-256 hashed, preserve expiry/revocation/last-use metadata, support configurable prefixes, and retain the Fonoteka extension columns needed for compatibility.
• Update the plugin README and configuration reference.

Task 2: Migrate Fonoteka to the shared token credential without breaking parity

• Replace the Fonoteka-owned token model/guard/manager with aliases or calls into sm-user-plugin; keep inv_token and inv.scope:* as compatibility middleware names.
• Add a data migration from golem15_fonoteka_api_tokens to user_api_tokens, preserving IDs, hashes, scopes, collection pins, OAuth client links, timestamps, and refresh-token foreign keys.
• Keep Fonoteka's existing token-management and OAuth endpoints byte-compatible while using the shared row/guard underneath; configure inv_ as this application's minting prefix.
• Update direct SQL/tests/fixtures and run focused plus full Fonoteka tests.

Task 3: Refactor BM management API to consume shared user tokens

• Preserve the current uncommitted management endpoints, but remove the plugin-local API-token model, migration, guard, and bm:token:* commands.
• Protect BM management routes with user.api_token and user.scope:*; enforce BM permission codes from the authenticated user's group-derived grants.
• Update BM's sm-user-plugin submodule pointer and app/plugin tests, ensuring a token minted once by the user plugin authenticates the BM API.
• Commit code atomically in each affected repository, then write the quick-task summary and update .planning/STATE.md without disturbing unrelated working-tree changes.

Verification

• gofmt clean in all touched Go trees.
• GOWORK=off go test ./... and go vet ./... in sm-user-plugin.
• Focused token, migration, OAuth, route, and parity tests in Fonoteka; then its full relevant suite.
• Focused management API and plugin tests in sm-bm-plugin, plus application build/test gates available in sm-bm-app.
• No live token secret is persisted or logged; old Fonoteka tokens authenticate after migration; one shared token authenticates both Fonoteka and BM plugin routes subject to scopes and user permissions.