# PR-20 Asset Action Capabilities and Register-First Delivery

Domain Owner: `docs/packer`
Cross-Domain Impact: `docs/studio`

## Briefing

The current `Assets` workspace still decides too much locally about which asset actions should appear and when they should be allowed.

That is the wrong long-term boundary.

The packer already owns asset semantics, registration state, build participation, and write execution. It should also own the capability decision for asset actions, while Studio remains a consumer that renders the actions exposed by the service.

This PR introduces a capability-based action contract driven by the packer, with `AssetAction.REGISTER` as the first delivered action end to end.

## Objective

Add a packer-owned asset action capability API and deliver the first action, `REGISTER`, through the full packer-to-Studio path.

## Dependencies

- [`./PR-15-snapshot-backed-asset-query-services.md`](./PR-15-snapshot-backed-asset-query-services.md)
- [`./PR-16-write-lane-command-completion-and-used-write-services.md`](./PR-16-write-lane-command-completion-and-used-write-services.md)
- [`./PR-17-studio-runtime-adapter-and-assets-workspace-consumption.md`](./PR-17-studio-runtime-adapter-and-assets-workspace-consumption.md)
- [`./PR-18-legacy-service-retirement-and-regression-hardening.md`](./PR-18-legacy-service-retirement-and-regression-hardening.md)
- [`./PR-19-api-surface-audit-model-separation-and-public-read-dtos.md`](./PR-19-api-surface-audit-model-separation-and-public-read-dtos.md)

## Scope

- define a public packer action contract for asset capabilities
- let the packer decide which actions are available for a given asset at a given moment
- let Studio render the action section from packer-provided capabilities instead of local semantic rules
- keep the capability contract stable even if the packer later moves to FSM or another internal decision model
- deliver `AssetAction.REGISTER` as the first supported action end to end
- keep the service-only wave focused on active functionality

## Non-Goals

- no FSM implementation
- no full action family rollout in the first delivery
- no doctor/build/reconcile action surfaces
- no speculative future actions without packer support
- no frontend-local capability engine

## Execution Method

1. Add a public action capability contract in `prometeu-packer-api`, including:
   - `AssetAction` enum
   - capability response shape for asset actions
   - request/response messages for reading action capabilities
2. Model the response so the packer can expose at least:
   - `action`
   - `enabled`
   - `visible`
   - optional `reason`
3. Add a runtime-backed read path in `prometeu-packer-v1` that resolves action capabilities from the current asset state.
4. Keep the internal decision logic inside the packer implementation. Studio must not reconstruct capability semantics.
5. Add a write path for `AssetAction.REGISTER`.
6. Expose `REGISTER` only when the asset capability resolver says it is allowed.
7. Render the `Actions` section in Studio from the returned capabilities.
8. Execute `REGISTER` from Studio through the packer write path and refresh the asset workspace after completion.

## Register-First Delivery Rules

The first delivered action is:

- `AssetAction.REGISTER`

Expected initial capability behavior:

- unregistered assets may expose `REGISTER`
- registered assets must not expose `REGISTER`
- Studio must only show the `Register` button when the packer returns that capability

Other future actions such as `MOVE`, `DELETE`, `INCLUDE_IN_BUILD`, `EXCLUDE_FROM_BUILD`, `ENABLE_PRELOAD`, `DISABLE_PRELOAD`, and `CHANGE_CONTRACT` are intentionally deferred from code delivery in this PR unless needed to support the contract shape.

## Acceptance Criteria

- the packer API exposes an asset action capability contract
- Studio reads action capabilities from the packer instead of deciding them locally
- the first delivered action is `AssetAction.REGISTER`
- `REGISTER` is available only for unregistered assets
- `REGISTER` is not shown for registered assets
- Studio can trigger `REGISTER` through the packer service path and refresh the workspace after success
- the capability contract remains valid if packer internals later migrate to FSM or another orchestration model

## Validation

- packer unit tests for capability resolution
- packer tests for `REGISTER` execution
- Studio tests or smoke tests proving that action buttons are rendered from service-provided capabilities
- end-to-end validation for unregistered asset -> register -> refresh -> registered asset

## Affected Artifacts

- `prometeu-packer/prometeu-packer-api/src/main/java/p/packer/**`
- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/**`
- `prometeu-packer/prometeu-packer-v1/src/test/java/p/packer/**`
- `prometeu-studio/src/main/java/p/studio/**`
- `prometeu-studio/src/test/java/p/studio/**`