Lucky.ai Auto Dev — Requirements v1.3.3
Date: 2026-10-02
Status: PASS FOR A0 ONLY NOW
Development authorization ≠ production release authorization.
Until the 2026-10-10 hearing ends, Claude work is session-based and Owner-started only. No unattended Claude.
0. North Star
Lucky.ai Auto Dev moves the Owner from:
Developer + QA + Release Manager
to:
Product Owner + Exception Handler
Claude may help discover, plan, code, test and repair, but:
- Claude never has root.
- Claude never directly releases production.
- Policy remains authoritative.
- Case content never enters the development domain.
- Auto Dev may develop control-plane code, but may never auto-deploy or auto-upgrade the control plane.
- Production auto-release remains OFF until G9 is explicitly enabled through root-owned policy.
1. Timing, Priority and Session Rules
1.1 Immediate scope
Before the hearing ends, the only authorized implementation start is:
- A0 read-only compatibility audit.
- After A0 is reviewed and passes, A1/A2 may be started in later Owner-started sessions.
- No unattended Claude before the hearing ends.
Do not interpret “start development now” as authorization for unattended work, production changes, root actions, G4b, G9, or production Release Agent installation.
1.2 Current priority: E0-Slim frozen, Auto Dev active
Owner has now explicitly frozen E0-Slim.
Therefore:
- E0-Slim must not be started, resumed, modified, tested, or used as an active development task unless the Owner explicitly unfreezes it later.
- Auto Dev is the current active development priority.
- Auto Dev runs in a separate Claude session and separate worktree.
- The Auto Dev task must not enter, modify, test, or inspect the E0-Slim worktree or its outputs.
- No resources need to be reserved for E0-Slim while it remains frozen.
- Production release freeze and hearing-week Owner-attention protections remain separate controls.
From 2026-10-05 through hearing end on 2026-10-10:
- no unattended Claude;
- Auto Dev runs only when the Owner explicitly starts a session;
- any Owner/root/security/product decision becomes WAITING;
- production release freeze remains active.
1.3 No unattended work before hearing
Option A is selected.
Until hearing end:
- no persistent Claude session;
- no systemd/tmux/screen/background Claude loop;
- no cron or scheduler that launches Claude;
- no autonomous D5/G3 start;
- no “continue while Owner is away”.
After hearing, unattended work can be reconsidered only after:
- D0/D1 permission separation passes;
- dedicated/capped dev model credential or equivalent usage-isolation exists;
- resource guards are active;
- hard timeouts are active.
2. Branch and Worktree Rules
devcontrol/d1 remains frozen and untouched.
Auto Dev must:
- create a new branch such as `autodev/a0` from the audited `devcontrol/d1` commit;
- create a separate worktree for Auto Dev;
- never commit directly to `devcontrol/d1`;
- never alter D2;
- keep Dev Control D2 frozen.
The Auto Dev worktree must not be the E0-Slim worktree.
3. Existing Dev Control v1.2 State Model Is Authoritative
Candidate states remain:
- DISCOVERED
- PROPOSED
- APPROVED
- AUTO_APPROVED
- PROMOTED_TO_TASK
- REJECTED
- DUPLICATE
- OBSOLETE
Do not introduce NEW / IGNORED / BLOCKED / CONVERTED database states merely for UI wording.
Low-risk auto-approved path:
DISCOVERED → PROPOSED → AUTO_APPROVED → PROMOTED_TO_TASK
Medium-risk path:
DISCOVERED → PROPOSED → APPROVED → PROMOTED_TO_TASK
High-risk path:
DISCOVERED → PROPOSED → REJECTED(reason=POLICY_BLOCKED)
Task states already implemented in Dev Control v1.2 remain authoritative.
CANCEL_REQUESTED must remain. A task is not shown as cancelled until the executor/worker confirms stop.
4. A0 Permission Audit Must Not Read Case Content
A0 may inspect:
- paths;
- owners;
- groups;
- mode bits;
- ACLs;
- mount options;
- whether the dev identity can open a protected file;
- whether the dev identity can write a protected path.
A0 must never:
- read file contents;
- print case filenames beyond the minimum path needed for the permission test;
- open E0-Slim worktree content;
- inspect E0-Slim outputs;
- parse case documents;
- query production DB rows.
If actual-open testing is necessary:
- open then immediately close;
- read zero bytes;
- record only success or permission-denied;
- permission-denied is the expected PASS for protected resources.
A0 must also record:
- every path/script/config that root executes;
- whether the dev user can write to any of them;
- whether a privileged launcher resolves or executes developer-writable code.
4.1 Secret-Safe Audit Rules
A0 must treat credentials and secrets as protected content, even when they are not case data.
A0 must never cat, print, copy, or otherwise emit values from files that may contain credentials, including but not limited to:
- `.env` files;
- systemd `EnvironmentFile` files;
- Cloudflare tunnel tokens;
- API keys;
- model/provider credentials;
- backup passwords;
- database passwords;
- service tokens;
- private keys.
For such files, A0 may record only:
- path;
- owner;
- group;
- mode;
- ACL;
- whether the dev identity can read/write it.
If configuration structure must be inspected, only key names may be shown and every value must be replaced with <redacted>.
The A0 report must contain no token, password, secret, private key, credential value, or secret-bearing URI.
4.2 Non-Mutating Write-Permission Tests
A0 must determine writability without mutating production or protected paths.
Allowed:
- `test -w <path>`;
- `access(W_OK)` or equivalent permission check;
- mode/ACL inspection;
- parent-directory permission analysis.
Forbidden:
- `touch`;
- opening with write/create/truncate flags;
- creating a temporary file inside a protected production directory;
- chmod/chown/setfacl;
- any write that changes timestamps, content, directory entries, or metadata.
If a protected path is unexpectedly writable, that is a finding to report. Do not “verify” it by writing.
For sudo inspection, the only allowed command is:
sudo -n -l
No other sudo command may be executed. Do not trigger an interactive password prompt.
4.3 Source-Only Schema Inspection and Case-Filename Minimization
Candidate/Task schema and enum discovery must come from:
- repository source code;
- migration files;
- schema definitions checked into the dev repository.
Do not open production dev_control.db or the production main database to discover schema or enum definitions, even read-only.
For case directories:
- do not list filenames;
- do not emit filenames into Claude context or reports;
- record only directory path, owner/group/mode/ACL, and an aggregate file count if needed.
Case filenames may themselves contain party/case details and are therefore treated as protected metadata.
5. Root and Windows Actions
Claude must never request, simulate, or perform root/admin actions.
If implementation requires:
- creating `luckybuilder`;
- creating `luckybridge`;
- installing systemd services;
- changing polkit/sudo;
- creating a Windows user;
- configuring WSL host-level settings;
- changing root-owned files;
Claude must:
- write an install script or exact command checklist;
- mark the step WAITING_FOR_OWNER;
- continue only with safe unprivileged work;
- not repeatedly ask the Owner during hearing week.
These steps remain waiting until the Owner explicitly executes them.
6. Separate Session, Worktree and Resource Controls
Auto Dev must use:
- a separate Claude session;
- a separate worktree;
- a separate task log;
- heavy-job concurrency = 1.
Any build/test wrapper must support:
- `nice` or equivalent CPU priority reduction;
- cgroup/systemd-run/resource limits when available;
- hard timeout;
- disk guard.
Before A1/A2 heavy work is allowed, the implementation must document a model-usage isolation mechanism:
Preferred:
- dedicated dev API/model credential with spending/rate cap.
If the current Claude product does not support a separate credential:
- record `DEDICATED_DEV_KEY=UNAVAILABLE`;
- do not fake one;
- enforce session-based manual start plus explicit usage budget/stop conditions;
- A0 may still proceed.
7. Explicit State Machine, Idempotency and Recovery
Every Candidate / Task / Run / Release operation must have:
- operation_id;
- run_id;
- deterministic transition rules;
- audit event;
- duplicate suppression;
- restart recovery;
- concurrency guard.
Retries must not duplicate:
- task creation;
- approval;
- release;
- rollback;
- notifications.
Claude cannot authoritatively write:
- verified test result;
- final release state;
- rollback success;
- production health result.
8. Release State Store Ownership
Release lifecycle must use a separate Release/Run store owned by the Release Agent trust domain.
Requirements:
- Release Agent is the only writer of authoritative release state.
- Dev Bridge and Claude are not allowed to mutate authoritative release state.
- Bridge/Claude receive copies through append-only events or read-only views.
- Approval records may be created by the approval service, but Release Agent independently validates them.
- Release state transitions are evented and idempotent.
9. Clean Builder and Artifact Store
Use a distinct builder identity such as luckybuilder.
Builder source must come from its own clean clone/archive of the exact commit.
Forbidden inputs:
- Claude working tree;
- untracked files;
- uncommitted changes;
- developer-home temporary files;
- case data;
- production credentials.
Dependencies:
- only from declared lockfiles;
- hash/integrity verification where ecosystem supports it;
- limited/allowlisted package mirror or registry;
- no arbitrary dependency URL discovered from runtime text.
Artifact store:
- only `luckybuilder` may write new artifacts/manifests;
- Release Agent reads artifacts but does not rebuild;
- Claude/Bridge cannot modify an existing artifact;
- artifacts are immutable by digest.
Required invariant:
release_artifact_sha256
== verified_artifact_sha256
== staging_artifact_sha256
10. CONTROL_PLANE_PROTECTED
Permanently protected:
- Release Agent;
- Dev Bridge;
- Policy Engine;
- Builder runner/service definitions;
- backup/restore control;
- rollback control;
- fresh-auth / approval security;
- worker auth/gateway;
- auth/session/network/Cloudflare control;
- privileged systemd/polkit/sudo/root integration.
Claude may develop and test them in dev.
Auto Dev may never production-deploy them, even with G9 ON.
Production install requires:
- Owner review;
- protected/manual root installation.
11. Release Agent
Properties:
- deterministic;
- model-free;
- no public hostname;
- no public release TCP endpoint;
- no generic shell endpoint;
- no root;
- no sudo.
IPC:
- Unix domain socket;
- filesystem ACL;
- OS peer credentials;
- allowlisted caller identity.
Release request validates:
- request ID;
- task ID;
- commit SHA;
- artifact digest;
- builder run;
- verified runs;
- staging run;
- policy snapshot;
- live policy;
- freeze state;
- approval if needed;
- expiry;
- replay/idempotency.
Live policy rule
A release is blocked if the current live policy is stricter than the policy snapshot used during verification.
A stale snapshot can never override a newer stricter live policy.
12. Backup Attestation Authenticity
Release Agent does not gain production DB read access just to create backups.
Backup attestation must specify:
- backup_id;
- database/storage set covered;
- created_at;
- integrity_verified_at;
- source release context;
- producer identity;
- attestation signature/MAC or equivalent protected provenance.
Only the protected Backup Service / root-owned backup path may write authoritative backup attestations.
Release Agent only reads/verifies the attestation.
Production release requires:
- backup covers every production datastore affected by the release;
- backup age is within root-owned freshness limit;
- integrity verification is successful;
- attestation provenance is valid.
Restore test may be periodic rather than per release.
13. Dev Verify Worker Boundary
Separate WSL distro alone is insufficient.
Minimum accepted same-PC design:
- separate Windows user;
- dedicated WSL distro;
- Linux user `luckyverify`;
- Windows interop OFF;
- automount OFF;
- Windows PATH not inherited;
- no C: mount;
- no user-profile mount;
- no case data;
- no Case Worker credential;
- no production credential;
- no model credential.
Before Claude-written E2E code runs, prove the worker cannot:
- access case files;
- invoke Windows tools to bypass isolation;
- invoke another WSL distro;
- access the Case Worker without authorization.
Failure means STOP and move to a separate machine/VM or equivalent verifiable isolation.
14. Dev Verify Worker → Staging Path
Define an explicit staging path.
Requirements:
- separate staging hostname from production;
- synthetic data only;
- dedicated staging identity;
- Cloudflare Access service token or equivalent machine credential;
- token scoped only to staging;
- no production hostname permission;
- no real case access.
The Worker must not reuse Owner browser cookies.
15. Safe Fault Injection
Allowed:
- injected ENOSPC;
- failpoints;
- quota-limited directories;
- bounded tmpfs;
- isolated sandbox.
Forbidden:
- filling VPS root FS;
- filling WSL VHDX;
- filling Windows disk;
- damaging global network/systemd/credentials.
16. Migration / Rollback
No migration:
- code-only automatic rollback may be enabled after its gate.
Any DB migration:
- AUTO_RELEASE = FORBIDDEN;
- AUTO_ROLLBACK = FORBIDDEN;
- manual approval/release required;
- explicit compatibility/recovery plan required.
17. Owner Approval and Fresh Auth
D-2 may be developed but remains OFF until fresh-auth passes.
Approval binds:
- owner;
- task_id;
- release_request_id;
- commit_sha;
- artifact_sha256;
- expires_at.
Preferred:
Passkey/WebAuthn step-up challenge including:
- release_request_id;
- artifact_sha256;
- nonce;
- expiry.
Long-lived app session or Cloudflare Access token alone is not sufficient recent-auth proof.
18. Production Synthetic Checks
Use:
- dedicated synthetic account;
- dedicated synthetic project/case;
- no permission to real cases;
- no real-case read/write.
Prefer no-model deterministic checks.
Any real model call:
- low frequency;
- separate budget;
- counted in Auto Dev cost metrics.
19. Monitoring and Low-Traffic Rollback
High-traffic signal:
- 5xx > 2% in 5 minutes;
- request count >= 20.
Low-traffic fallback:
- critical healthcheck fails twice; or
- critical synthetic transaction fails twice; or
- browser smoke reaches configured consecutive-failure threshold.
Low traffic must not disable rollback protection.
20. Freeze Window
Default:
5 days before hearing → hearing end.
For 2026-10-10 hearing:
production release freeze begins 2026-10-05.
Freeze:
- blocks new production release;
- does not block supervised dev-only work;
- does not block necessary rollback.
21. Notifications
Default:
- low/medium normal events → overnight brief only;
- no nighttime Owner interruption.
Immediate notification channel for severe production incident/rollback remains an explicit Owner decision.
Until configured:
- log event;
- do not invent external notification channel.
22. Production Signals
Use existing G4b.
No duplicate G10.
G4b default = OFF.
Allowed:
- counts;
- latency;
- status aggregates;
- job failure counts.
Forbidden:
- prompt content;
- case text;
- uploaded file contents;
- generated legal document contents.
23. G9
Historical rule: root production release is manual.
G9 is the only explicit limited supersession.
G9:
- must be explicitly enabled by Owner + root-owned policy;
- applies only to AUTO_ELIGIBLE application releases;
- never covers CONTROL_PLANE_PROTECTED;
- never covers DB migrations;
- is independently reversible.
24. Resource and Cost Protection
Before continuous discovery or any future unattended mode:
VPS
- heavy-job concurrency = 1;
- production priority;
- nice/cgroup limits;
- disk guard;
- artifact/log/worktree TTL;
- hard operation timeout;
- queue backpressure.
Model cost
- daily budget;
- monthly budget;
- discovery-frequency cap;
- max repair rounds = 2;
- Candidate analysis cap;
- no 24/7 Claude session.
Correct future discovery design:
scheduler
→ deterministic collectors
→ structured signals
→ dedup
→ confidence gate
→ budget gate
→ Claude on demand
Hard timeout
Every autonomous operation must have a hard timeout.
On timeout:
- executor terminates;
- cleanup runs;
- state becomes FAILED or NEEDS_ATTENTION;
- Claude cannot extend its own timeout.
Candidate noise budget
Must include:
- fingerprint dedup;
- confidence threshold;
- per-cycle Candidate cap;
- repeated-signal aggregation;
- per-day analysis cap.
Worker idle policy
No persistent browser or model workload while idle.
Soft/hard thresholds
For disk, CPU, RAM, daily model use, monthly model use, and queue length:
- warning threshold;
- hard-stop threshold;
- emergency reserve.
Hard-stop logic is deterministic and outside Claude control.
25. Immediate Allowed Scope
Before hearing, the current authorized step is:
A0 only.
After A0 is reviewed and passes, the Owner may start A1 and A2 in later supervised sessions.
Do not:
- modify `devcontrol/d1`;
- unfreeze D2;
- install production Release Agent;
- apply root/Windows changes;
- read case contents;
- enter E0-Slim worktree;
- enable G4b;
- enable G9;
- run unattended Claude.
26. Verdict
STATUS = PASS FOR SUPERVISED A0 NOW
A0 must run:
- in a new `autodev/a0` branch/worktree cut from the audited frozen `devcontrol/d1` commit;
- in an Owner-started separate Claude session;
- while E0-Slim remains frozen and untouched;
- read-only with respect to production;
- without case-content access;
- without root/admin actions.