Approved by Product Owner • August 8, 2026

Kuberan autonomous execution plan

This plan authorizes Codex to continue the approved SRS through the maximum software scope that can be completed safely on macOS with SQLite, simulators, headless tests, independent reviews and HTML evidence. It does not authorize production deployment, real money, real customer data or external commitments.

Approved execution authority: continue autonomously from the current V0.5 checkpoint through all implementable V1.0 release-candidate work. When an external decision or validation gate is reached, park it as Owner validation required, prepare the validation package and continue every dependency-safe engineering item. Do not push, deploy, spend money, accept legal terms, use real store data or activate production providers without separate approval.

1. Current baseline

Area	Position at approval
V0.2 technical foundation	Complete Six phases passed implementation, evidence and independent audit.
P05-1.1 shared UI/accessibility	Complete Implementation, tests, evidence and independent audit passed.
P05-1.2 local identity/policy	Complete Second concurrency remediation, independent re-audit and linked evidence passed.
P05-1.5 eight app identities	Complete Eight identities/builds, canonical-version preflight, independent re-audit and linked evidence passed.
All other V0.5/V0.8/V1.0 work	Not started unless explicitly shown otherwise in the SRS progress register.

2. Autonomous operating model

Small unit

Work on one SRS child package with one bounded outcome. A package must be reviewable without completing its entire parent phase.

Independent gate

The implementer cannot approve their own work. A separate read-only reviewer runs negative, restart, offline, permission and recovery checks as applicable.

Evidence before credit

A child is marked Done & tested only after repeatable tests, an HTML/JSON evidence record, traceability and independent acceptance pass.

Maximum concurrency

At most three bounded lanes run beside the integration owner. Shared migrations, money/tax rules, public contracts and signing formats remain serialized.

Read the applicable SRS child, contract, fixtures and existing code.
Implement only that child package and its focused tests.
Run headless analysis, positive/negative tests and proportional integration checks.
Assign an independent read-only audit.
Correct audit findings autonomously and rerun the same gate.
Create/update HTML evidence, machine traceability and SRS status.
Create a local checkpoint commit when FileProvider/Git is healthy; never push without approval.
Start the next dependency-safe child package.

3. Work I may do without asking again

Implement Java 21/Spring Boot and Flutter/Dart code already within the approved SRS.
Create and migrate Store, License Cloud and client SQLite schemas using reversible or safely rehearsed migrations.
Define versioned OpenAPI, event, licensing, compatibility and evidence contracts without changing approved business scope.
Build simulators for processors, hardware and future provider boundaries; AI remains non-callable through V1.0.
Create synthetic/golden test data, HTML guides, runbooks, SRS status, screenshots/goldens and evidence.
Run headless local services, temporary databases, real-JAR tests, Flutter tests, load tests and fault injection on this Mac.
Choose ordinary implementation details—class/module structure, internal algorithms, safe UI copy and test organization—consistent with the SRS.
Fix defects found by independent agents and repeat the gate until it passes or reaches the escalation rule.

4. Owner-validation parking gates

I will not perform or self-certify an action in this table. I will mark it Owner validation required, prepare the simulator, checklist, evidence and exact steps for you, and continue all other dependency-safe work without waiting. I stop only if every remaining item depends on unresolved external input.

Gate	Why your approval or another person is required
Physical devices and payment certification	Requires your scanners, printers, scales, drawers, terminals, cabling and processor/acquirer participation.
Production credentials or paid services	Includes Apple Developer signing/notarization, payment/billing providers, email/SMS, hosting, OpenAI/Anthropic and any purchase.
Real store/customer/employee/bank data	Requires explicit privacy, consent, retention and environment authorization.
Tax, legal, accounting or commercial policy acceptance	HST working reports can be engineered and tested, but an accountant/legal owner must approve treatment and wording.
Destructive or irreversible migration	Any operation that could make real data or a supported downgrade unrecoverable needs an explicit go/no-go.
Shadow, limited-lane or whole-store pilot	Requires named authority, real people, schedules, rollback ownership and store-owner acceptance.
Thirty-day soak/release pilot	Requires elapsed time, release-candidate hardware, operating hours, daily reconciliation and restart-clock decisions.
Production deployment, push or public release	No Git push, PR merge, hosted deployment, Stable-channel release or customer communication without approval.

5. Execution roadmap after approval

Wave A — finish the P05-1 Flutter/store foundation

P05-1.1: publish passed UI/accessibility evidence.
P05-1.2: fix denied-decision clock pin; add expiry→rollback→restart tests; re-audit; publish evidence.
P05-1.5: enforce canonical package version before build; add mismatch tests; re-audit; publish evidence.
P05-1.3: pairing, revocation and device-policy refresh.
P05-1.4: shared outbox/pull integration, restart recovery and revoked/stale-permission behavior.
P05-1.6: compose assigned V0.5 workflows into the appropriate apps; keep other shells explicitly packaging-only.
Run the P05-1 parent gate across eight app identities, accessibility, SQLite, authorization and offline restart.

Wave B — P05-2 catalogue to receipt

Implement in order: product/UPC/PLU/UOM → effective price/tax/deposit → promotions/coupons → basket/weighed item → suspend/void/cancel/receipt → controlled return. Close with golden grocery baskets and receipts.

Wave C — parallel V0.5 stock, licensing and appliance lanes

After frozen product and foundation contracts, run three bounded streams: P05-5 inventory/purchasing, P05-6 Starter registration/licensing and P05-7 first boot/import/update/backup/recall/emergency readiness. Each child closes independently.

Wave D — P05-3 tenders and P05-4 cash controls

After receipt finality: cash tender → debit/credit simulator → split/partial → inquiry-before-retry → refund/reversal → reconciliation, alongside till/float → movements → blind count → safe/deposit → exceptions. Close with one opening-to-close reconciliation.

Wave E — V0.5 pilot-ready package and external gate

Autonomously complete the sandbox, shadow-comparison tooling, training-lane scripts, cutover matrix, daily reconciliation, failure drills and rollback package. Then pause for approval before using a real store or real tenders.

Wave F — V0.8 operational breadth

After the V0.5 gate, implement P08-1 through P08-6 in separate domain streams: food safety/fresh; staff/time/payroll; customer/stored value; finance/bank/HST; loss/maintenance/continuity; paid licensing/License Manager. Integrate Manager/Owner views in P08-7. Prepare P08-8 and pause for the external whole-store pilot.

Wave G — V1.0 release-candidate certification

Autonomously perform correctness closure, automated security/privacy/accessibility work, synthetic capacity/offline tests, installer/migration/support tooling and continuity/release operations. Pause for independent penetration/manual accessibility, physical-hardware certification, real nontechnical-user sessions and the 30-day release pilot. After external results are supplied, assemble—but do not publish—the final GA decision package.

6. Progress reporting and escalation

The SRS is updated whenever a child moves between Not started, In progress, Verification pending, Done & tested or External validation pending.
The HTML evidence index is updated only after an independent pass.
Ordinary audit defects are fixed autonomously; I do not ask you to approve routine code corrections.
If the same blocker survives three consecutive remediation/audit cycles, I stop and present the exact evidence and choices.
If a new choice changes product scope, money/tax behavior, data authority, licensing policy or external commitments, I stop before implementing that choice.
All tests remain headless by default. I will not leave visible test applications or service processes running.

7. Expected autonomous stopping points

Target	What I can complete alone	What remains external
V0.5	Pilot-ready code, simulators, eight apps, installers, reconciliation, runbooks and evidence.	Physical payment/hardware testing and approved limited-store pilot.
V0.8	Whole-store operational code, bank/HST workpapers, payroll/accounting adapters, License Manager and rehearsal evidence.	Accountant acceptance, real provider credentials and whole-store pilot.
V1.0 candidate	Release-candidate code, automated certification, migration/support/continuity packages and signed-build tooling.	Independent/manual sign-offs, real appliance certification, 30-day pilot and GA go/no-go.

Approval recorded: the Product Owner approved this autonomous execution plan on August 8, 2026. Execution resumed from Wave A and continues without routine engineering approval, stopping only at the mandatory gates above.

Kuberan SRS v1.0 remains the scope authority. This operating plan changes task sizing and approval cadence, not product requirements, technology choices or roadmap versions.