Daily Workflow¶
EmbrAIon should make AI-assisted engineering more disciplined, not more ceremonial.
In plain English
Most days you should talk about the product, not the framework.
A normal day¶
| Step | What you do | What EmbrAIon contributes |
|---|---|---|
| 1 | Ask for the engineering outcome | Project knowledge, policy, roles, and optional routing are already attached to the repo |
| 2 | Let the host implement | Host-native AI does the reasoning/tools |
| 3 | Finish author self-review and required tests/CI | Current-candidate evidence establishes review readiness |
| 4 | Run a separate read-only Reviewer in the current host | Existing project routing supplies the reviewer; fixes receive checks and final SHA confirmation |
| 5 | Merge/deliver | Optional enforcement can make selected gates deterministic |
Example:
Fix the retry flow and add regression coverage.
That should normally be enough.
Before substantial or suspicious work¶
embraion doctor
embraion status
Use diagnostics after framework updates, before substantial work, or when project behavior looks wrong — not as ceremony before every tiny change.
Behind the scenes¶
The project contract can supply architecture knowledge, protected/private path rules, project-specific specialists, optional model/deployment routing, validation profiles, and review requirements.
Configuration changes are different from product work¶
This changes the AI-engineering system:
Configure routing so complex architecture uses our reviewed deployment.
This does not:
Fix the reconnect bug.
For ordinary product work, the host should use the existing project contract rather than casually rewriting it.
Validate¶
embraion validation run affected
If the profile is empty, configure it first. skipped is not equivalent to passed.
Review and finish¶
Ask:
- Did the requested behavior change correctly?
- Did relevant validation pass?
- Were protected/canonical boundaries respected?
- Did an independent Reviewer confirm the exact final PR-head SHA after fixes?
- Is residual risk explicit?
Every PR requires the host-native review lifecycle. Start independent review only after implementation, self-review and required checks are complete. No Copilot Review service is required. Any subsequent commit invalidates reviewer confirmation; user merge/release authorization remains separate.
If CI enforcement is installed, it can make selected gates deterministic at merge time.
After an EmbrAIon upgrade¶
pipx upgrade embraion
cd MyProject
embraion update
embraion doctor
embraion projection diff --host codex --destination .
Updating project configuration does not silently rewrite host projections.