Use case

Customer portals

Authenticated, customer-facing surfaces where a mistake is public.

The situation

A customer portal is the part of your system your customers actually see, and the part where an authorization mistake is not an internal embarrassment but a disclosure. The work is mostly unglamorous — sessions, permissions, pagination, empty states — and it is precisely the unglamorous parts that leak data when rushed.

How Fidelio handles it

The same loop, applied to this problem.

01

Access rules are stated up front

Who may see what belongs in the intent, not in a code review comment three weeks later. Fidelio turns those rules into an explicit part of the plan, so the boundary is a reviewable artifact rather than an assumption distributed across handlers.

02

The reviewer looks for what the builder assumed

An independent reviewer grades the build against the stated intent. It is checking the thing that is hardest to catch in your own work: the case you did not think of because you were the one who thought of the design.

03

You control the release

Portal changes ship when a human approves them. There is no configuration in which a run promotes itself to a customer-facing surface.

Concretely

Things teams actually ask for.

Written the way a request arrives, not the way a feature list describes it.

  • A billing history view scoped strictly to the signed-in account
  • A document vault where every download is authorized and logged
  • A self-service plan-change flow with a confirmation step
  • An invite system where a revoked invite stops working immediately
Questions

Common questions.

Does Fidelio handle authentication itself?
Fidelio builds against the authentication approach described in your intent. The important part is that the access rules become an explicit, reviewed element of the plan rather than an implicit property of the code.
How do I know the portal does not leak between accounts?
State it as a requirement in the intent. It then appears in the plan and is something the independent reviewer grades against, and the verdict is attached to the run you approve or reject.

Put an intent in and see what comes back.

Every run produces a plan, a build, an independent review, and a gate you control.