An architecture is a set of rules the compiler cannot enforce. FlowIoC writes them down twice: once as editor tools for the team, once as files for the assistants they work with.
01Rules where assistants already look
A versioned rule block in AGENTS.md, with CLAUDE.md pointed at it: the files Claude Code, Codex, Cursor, Zed and Gemini CLI read. The editor keeps it current and never touches a line outside its markers.
<!-- FLOWIOC:BEGIN version=… -->
02A skill for each kind of work
Eight skills land in .claude/skills when the Editor opens: scaffolding, commands, screens, connectors, systems and services, models, root order, data types. An assistant handed the shape of a Command does not read half the repository to infer it.
.claude/skills/flowioc-controllers/SKILL.md
03A card on every module
Each MODULE.md says what the module is for and the words someone would search for. A generated block lists its signals and assemblies, and every card is gathered into one MODULES.md.
Assets/Plugins/FlowIoC/MODULES.md
04One file tells the whole flow
A Context declares every step an operation runs, in order. Reading it is enough to know what happens, without opening each Command.
.ToSequence<SavePlayerCommand>()
05The same generators, from a terminal
The tools a person clicks can be driven from a terminal against an open Editor, so an agent lays a module out exactly the way the team does.
unity command eval '…'
06Boundaries that hold
Modules never reference one another; a Connector is the only place two meet. The rules name the usual slips: logic in a Context, reaching into another module's model, [Inject] on a field.
InjectionBinderCrossContext.GetInstance<T>()