Jake Tae-moon Jo · Engineering lead · https://jake-jo-portfolio.vercel.app/en/process/
This is how I set up and ran the work on the 2026 EWA platform, and how that setup changed across six 2026 projects. Every change request from the client was shipped within 24 hours. I defined an 8-stage pipeline and assigned design, implementation, QA and review to a 13-role AI agent team. The client's stakeholders supplied the requirements and the decision-sheet answers; I confirmed or gave input on decisions taken by default, and gave the go for production.
The eight stages in the middle are assigned to role agents. At the top the client supplies requirements and I confirm or give input on decisions taken by default; at the bottom I give the go for production.
Click a node, or Tab to it and press Enter, to highlight its note. Rounded, heavy boxes are the client's. Filled rounded boxes are mine. Dotted rounded boxes are rules that never fired.
Scroll sideways for the rest →
Client → Intake: source docs
Intake → Architect
Architect → Sign-off · input: defaults logged
Architect → Design
Design → Develop
Develop → QA
QA → Review gate
Review gate → Develop: rejected
Review gate → Escalation: rule
Review gate → Integrate
Integrate → Document
Document → Deploy
Release go-ahead → Deploy: on my go
Node notes
Features come from five documents by the client's stakeholders, merged into the spec that the story IDs come from. The answers in the stakeholders' decision sheet of 3 July went in together as decisions D-128 to D-131 on 4–5 July.
Checks the story ID and its acceptance criteria. The rule is that every feature traces to a story ID in the spec; 61.4% of the 1,855 non-merge commits carry one.
Data model, API contract and ADRs. When a choice is needed, it goes ahead on a recommended default so work never blocks, and logs it in the decision register.
68 of the 199 rows carry a person's confirmation or input, 37 of them with my name. 3 of the 11 hard-to-reverse ones were confirmed when logged; the rest follow the default-now, review-later mode. 26 earlier rows were reversed by later ones (some the same day), and a row that reverses an earlier one names it.
Screen and flow specs per story. Some rows reversed an earlier decision because of the design file (D-141, D-156).
The rule is to write the failing test first; 86.4% of the 398 non-merge fix commits also changed a test file. Web types are generated from the OpenAPI snapshot, and the app's models are written by hand (D-009).
A pass or fail verdict for each acceptance criterion; a failure goes back to the responsible developer with the repro.
Three reviewers are in the pipeline: security when money, auth or personal data is touched, code always, and API contract when the contract or a client changes. An unresolved blocker or major finding, or any CRITICAL or HIGH security finding, fails the gate and goes back to development. Since 28 Sep, when records begin, they ran 24 times (code 12, security 10, contract 2); the spec coverage auditor sits outside the pipeline and ran 0 times.
If a review-and-fix loop repeats more than twice on the same finding, it stops and comes to me. This is a rule in the orchestrator's instructions; no case is on record.
Merges happen locally, without PRs (275 merge commits). The merge order is agreed first and conflicts are checked with git merge-tree.
Updates READMEs, runbooks and the decision register. Rules such as "a row that reverses an earlier decision says which one" also end up in the README.
Pushing, production deploys and store submission run on my go; that is the rule. On staging, any delete-like command makes a hook ask for confirmation first.
On my go, an agent session rolls the change out to production. Deploys are manual (ship a source archive, rebuild on the server).
The rule: every feature traces to a story ID in the spec, and branches, commits and PRs carry the ID. In practice 61.4% of the 1,855 non-merge commits carry a story ID, and 70.8% carry a story ID or a decision number. There were no PRs, and 15 of the 200 branch names contain a story ID.
Instead of blocking, go ahead on a recommended default, log it, and review the defaults later in one pass. 192 of the 199 rows say how hard the decision is to reverse, and 11 are hard, locking in data or contracts. Of those, 3 were confirmed by a person when logged and 8 went ahead on the default. A row that reverses an earlier decision names it.
The rule: write the failing test first. 86.4% of the 398 non-merge fix commits and 87.7% of the 764 feat commits also changed a test file. That includes edits to existing tests, so it does not mean a regression test was added each time.
The one contract between repos is the backend's OpenAPI snapshot. The web generates its types from it; the app's models are written by hand (D-009, code generation deferred). When the contract changes, the API contract check looks for drift between the web, the app and the backend.
Architect
1 more
Parallel sessions
Several agent sessions run at once. Each session uses its own worktree and announces the files, decision numbers and migration names it will touch. A decision number is taken as max + 1 at the moment of writing.
Develop
Integrate
Quality gates
Security review
An adversarial review of any change that touches withdrawals, settlement, payouts, auth, permissions or personal data; it does not edit code. Since 28 Sep, when records begin, it ran 10 times. 30 fix commits mention security review or a security fix (Jun 14 – Oct 29).
Review gate
Code review
Correctness, repo conventions, simplicity and test quality on every change. Findings are graded blocker, major, minor or nit, and the verdict is APPROVE or REQUEST-CHANGES. It ran 12 times since 28 Sep.
Review gate
API contract check
When the contract or a client changes, it checks that the web and the app match the backend's OpenAPI. It ran twice since 28 Sep.
Review gate
Rejection and escalation
An unresolved blocker or major finding, or any CRITICAL or HIGH security finding, counts as a failed gate and goes back to development. A further rule sends a review-and-fix loop to me once it repeats more than twice on the same finding. Both are rules in the orchestrator's instructions, and no escalation is on record.
Review gate
Escalation
1 more
Guardrails
Permission settings block force-push, reset --hard and rm -rf, and three of the four repos also block reading .env. A hook asks for confirmation before every delete-like command sent to the staging server.