---
name: seviaflow-app-planner
description: "Use after application discovery or when planning a SeviaFlow application. Map approved requirements to the installed SeviaFlow capabilities, package profile, Resources, authorization, routes, implementation stages, and verification."
---

# SeviaFlow App Planner

Translate an agreed application brief into a practical architecture and staged implementation plan. Use SeviaFlow's built-in capabilities where they fit, while keeping application-specific business rules in the host Laravel app.

## Inspect before planning

1. Read the approved brief and current user instructions.
2. Inspect the repository, its project guidance, Laravel version, composer.json and composer.lock.
3. Establish which SeviaFlow packages and versions are actually installed. If source is available, inspect its configuration, Resource base classes, examples, tests, and relevant package code.
4. Read the matching SeviaFlow documentation pages. Treat the installed package and its tests as authoritative when documentation and code differ.
5. If no project or package source is available, state that limitation and do not invent method names, route behavior, or configuration keys.

## Map needs to the product

For each requirement, classify the implementation as one of:

- A documented SeviaFlow capability that fits directly.
- A documented capability that needs host-application configuration.
- Laravel application behavior, such as a model, migration, policy, service, or integration.
- A genuine gap that needs custom code or a product decision.

Consider the relevant capabilities rather than adding all of them automatically:

- Core Resources connected to Eloquent models.
- Forms, sections, fields, tables, columns, search, and filters.
- Relationships, actions, bulk actions, events, and workflows.
- Import and export.
- UI adapter pages, navigation, dashboards, and saved views.
- API adapter routes, explicit per-Resource API contracts, and OpenAPI.
- Laravel policies, the Core role-permission checker, UI panel access, and Resource query scoping.

Prefer an existing capability over a parallel custom implementation, but do not force a framework feature where ordinary Laravel code is a better fit. Distinguish panel entry, per-operation authorization, and tenant/row scoping; they solve different problems.

## Produce the plan

Include:

1. The selected package profile and why it is sufficient.
2. A domain model: records, fields, relationships, ownership, and state transitions.
3. A Resource map: proposed class, model, stable slug, UI/API surfaces, and relevant built-in features.
4. Authorization and data-isolation design, including the host application's responsibilities.
5. Integrations, background work, imports/exports, and failure handling where required.
6. Ordered implementation stages with a reviewable outcome for each stage.
7. Tests and manual checks for each important behavior.
8. Risks, open decisions, assumptions, and features intentionally deferred.

Use tables when they make the mapping easier to review. Explain technical choices in plain language for a beginner, and define any necessary Laravel or SeviaFlow terminology.

## Do not guess or overbuild

- Do not claim a feature exists until it is present in the installed version or documented for that version.
- Do not invent Resource methods, field classes, config keys, commands, middleware, or migrations.
- Do not assume API installation exposes every model. Check whether each Resource explicitly opts in.
- Do not treat a UI panel gate as API authorization, or a query scope as a replacement for policies.
- Do not add workflows, API endpoints, roles, dashboards, or other modules just because they exist. Add them only when they support an agreed requirement.
- Keep the MVP small, and label optional improvements separately.

If the user asked you to implement the application as well as plan it, give a short plan and then continue into implementation rather than ending with the plan alone.