A package is the feature boundary. It names the product material the feature owns so the rest of the product can use it without guessing.
A customer dashboard owns customer records, a package-owned formatter, and a callable archive target. Those belong together because they change together.Record
Declare the records the feature owns.
+
File
Attach text, JSON, or other bytes the package needs.
+
Slot
Declare the named target the surface may request.
Authoring rule
Put something in the package when it is part of the feature’s contract. Keep it out when it is only local developer convenience.| Product need | Package shape |
|---|---|
| A durable customer, invoice, game room, note, or project item | record |
| Text, JSON, rules, or other bytes owned by the feature | stored_bytes |
| A named action the surface can request | slot |
| A screen placement decision | Surface descriptor or shell placement, not a package record |
| Account checkout or device activation | Account lifecycle docs, not a feature package |
Example boundary sketch
Common failures
| Symptom | Cause | Fix |
|---|---|---|
| The surface imports or parses file names | The package did not provide a named data read contract | Add a data name and read it through Runtime Kit |
| One package has unrelated product areas | The package file is too wide | Split by feature ownership |
| The package contains UI placement policy | The shell/surface boundary is blurred | Move placement meaning to the surface descriptor or shell route |
| An action name is vague | The caller cannot tell what action is safe | Rename it around product action, like customers.archive |
Verify
The package file is ready when a teammate or reviewer can answer these questions from the boundary alone:- What product facts does this feature own?
- Which bytes are package-owned material?
- Which callable targets exist?
- Which surface reads are expected?
- Which user action maps to each target?