---
name: seviaflow-resource-builder
description: "Use when implementing an approved SeviaFlow application plan in a Laravel repository. Build models, migrations, Resources, registration, adapter surfaces, authorization, and tests using the exact installed package APIs."
---

# SeviaFlow Resource Builder

Implement a reviewed SeviaFlow plan in the host Laravel application. Follow the installed package version and existing repository conventions. Prefer the framework's documented features over duplicating them in application code.

## Verify the project first

1. Read repository instructions, the agreed application brief, and the relevant plan.
2. Inspect composer.json and composer.lock to identify the Laravel and SeviaFlow versions and installed adapters.
3. Read the relevant SeviaFlow documentation and inspect existing Resources, package source, configuration, and tests. Use the nearest working example in this repository.
4. If the package source or version cannot be verified, avoid speculative APIs. Implement only verified Laravel-side work and clearly report what could not be confirmed.

## Implement in a traceable order

For each agreed feature:

1. Define or update the host application's migration and Eloquent model. Use database constraints, casts, relationships, and mass-assignment rules that match the requirements.
2. Add a Resource only after verifying its base class and supported methods in the installed version. Set its Eloquent model and implement only the required form, table, show, query, workflow, event, relation, action, or import/export definitions.
3. Register the Resource with the explicit slug map in the host config when required. Preserve existing entries and use a stable, readable slug.
4. Add the chosen adapter surface. UI and API are separate adapters. Do not install or expose an adapter that the agreed application does not need.
5. Add host-application authorization and business rules. Keep responsibilities clear between Laravel policies, SeviaFlow role permissions, UI panel access, and row-level query scoping.
6. Add focused tests and run the repository's established checks.

## SeviaFlow rules to verify in the installed version

- A Resource is model-backed. Confirm the exact required model property and namespace from the installed base Resource.
- Resource registration is explicit; do not assume that creating a PHP class makes routes or navigation appear.
- UI forms and tables use documented SeviaFlow field, column, and filter types. Verify class names and builder methods before using them.
- A Resource API contract is opt-in. If the API adapter is installed, explicitly allow the intended readable, creatable, updatable, and deletable fields/operations. Do not expose all model columns by default.
- Confirm the API adapter's authentication middleware and token/session configuration. A free API is not a public or anonymous API.
- For the documented SeviaFlow UI, configure the host's Core permissions.admin_gate. The default missing callback fails closed. This panel gate does not authorize API requests.
- If the model has a Laravel policy, ensure the required abilities are implemented. Verify how the installed Core version behaves when a policy or SeviaFlow role permissions are absent; never rely on an assumed default for sensitive operations.
- Use Resource query customization for intended row/tenant filtering only after inspecting how it applies. Do not use it as the only control for individual create, update, or delete operations.
- Keep generated or DevTools-created code under review. Check its model fields, relationship names, authorization, registration, and version compatibility.

## Quality and safety

- Keep the diff within the requested scope. Do not refactor unrelated modules.
- Do not put secrets, production tokens, or real personal data into source files, fixtures, prompts, or examples.
- Make migrations reversible when practical and verify rollback behavior without destroying user data.
- Use existing naming, formatting, test, and service patterns in the repository.
- Run the narrowest relevant test first, then the project's required checks. Do not claim checks passed unless you ran them.
- Report completed behavior, tests, assumptions, and any missing package/API verification. If a verification check fails, diagnose and fix it when within scope.