Concepts
How profiles work
A profile owns a set of domains and gives them meaning. UI, errors and logs are the first three; the spec lets anyone write more.
Profile, domain, intent
The core knows the shape of an intent (description, refs, binding, notFor, keywords, checks, status) and the engine that validates registries, finds usages and runs checks. It has no list of domains and no idea what UI is. A profile owns a set of domains, says what a binding means for them, how bindings combine, and how to find and check usages in code. A domain is a kind of thing; an intent is one meaning within it: text is a kind of UI and text.caption a meaning; conflict is a kind of error and conflict.duplicate a case of it.
The three profiles
- UI
- Errors
What went wrong, and what is the caller told?
@prongsjs/errors· used throughfail()· domains:request.*,auth.*,permission.*,record.*,conflict.*,limit.*,failure.* - Logs
What happened, and who needs to know?
@prongsjs/logs· used throughlog()· domains:audit.*,security.*,incident.*,job.*,debug.*
Each ships starter intents and the same parts: ref-only intents that hold the shared binding (looks for UI, statuses for errors, levels for logs), meaning intents built on them, helpers the project owns, and checks. Profiles can point at each other: an error names the log entry it writes, so failure.internal always writes incident.failed.
What makes a profile
A profile is worth shipping when its meanings are the same in every app, choosing between them is a judgment call, and nothing else checks that choice. UI, errors and logs pass all three. Domains whose intents would differ in every app, like an app’s own endpoints, or whose choices are already checked, like types, are left to the tools that cover them.
These three are the first, not the last. A profile is a set of domains, what a binding means for them, and how to find and check them in code, and the Prongs Intent Spec defines each part, so anyone can write one and any tool that reads a registry can use it.