dogfoodinglisted

# Building Syntropic inside Syntropic ## Overview Work on this repo defaults to running **through Syntropic on the Mini**, not on the laptop. That is the point of the project: the fastest way to find what the platform cannot do is to try to build the platform with it. Every capability gap recorded in this file was found by a run failing, not by reading code. One deliberate exception, and it is a security boundary rather than a defect: see Principle 2. ## Outcomes we are looking for ### Outcome 1: the platform is exercised by its own development Real work is dispatched to Syntropic rather than done locally out of habit. - *Signal:* on any given working day, the most recent execution is hours old at most, not a day. - *Signal:* capability gaps arrive as failed or degraded runs with an execution id attached, not as speculation. ### Outcome 2: agents never gain write access to CI The GitHub App installation cannot modify `.github/workflows`, and nobody "fixes" that by widening the token. - *Signal:* `workflows` permission stays off the installation, and workflow changes land in commits pushed from a human-controlled machine. - *Signal:* a task that needs a workflow change is recognised BEFORE the work is done, not after a rejected push. ### Outcome 3: a blocker is scoped to what it actually blocks A narrow failure does not silently become a reason to stop dispatching. - *Signal:* after a run fails on a path restriction, the next dispatch happens the same session. ##