“Sign in again”Console tabProxy settingsRunbookChat replyRetry later
The person becomes the coordinator.
THE NEXT LAYER OF THE APP FACTORY
Automation keeps moving.
People clear
the exceptions.
One place to see what needs you, open the right workspace, perform the action, and hand it back.
THE RECOMMENDATION
Add Actions to Studio. Keep the existing build and release engine. Make every human dependency a tracked task with a prepared workspace and a verified return path.
01 / WHAT CHANGES
The gap is the handoff.
The system can describe a blocker. A person still has to reconstruct the context, find the right session, and tell the system what happened.
01 What is blocked02 Where to act03 What to do04 How we check
The person performs a bounded action.
Grounded in our historyLost signing key → recovery wait ↗Late worker result → claim guards ↗Proxy failure → manual dependency ↗
Historical repository evidence, not live account status. The proxy change is on a sibling branch. This report inspects the current baseline and cited history; it does not operate any store account.
02 / THE OPERATING MODEL
Prepare → act → prove → continue.
Human work becomes a normal part of the pipeline, with its own history and success condition.
Detect
Identify the root dependency. Group affected apps.
Prepare
Openable workspace, files, instructions, expected result.
Perform
Sign in, answer, upload, approve, or explain what changed.
Verify
Read the real outcome against the intended account and release.
Continue
Resume eligible work within existing authority.
↶ Different screen or failed check? Update the same task with new evidence and a clear next step.
03 / CLICK THROUGH THE EXPERIENCEEverything needed.
Everything needed.
Exactly where it belongs.
Choose a task, explore its prepared workspace, and simulate the return. Every action below is a local demonstration.
PUBLISHER
UNLOCKS
PREPARED
Your steps
Choose the verifier’s simulated observation:
In the real desk, a task link resolves the approved session. Passwords and SMS codes are entered directly into the platform. No secret fields belong in this task card.
No scavenger hunt.
The correct build, account context, latest observation and instructions travel together.
Return any useful result.
A status, receipt, document, URL, answer, secure reference, or a new problem description.
“Done” starts a check.
Waiting for a store remains waiting. A verified result unlocks the next eligible step.
04 / SYSTEM ARCHITECTUREA new desk.
A new desk.
An existing engine.
Keep the current scheduler, harness, release authority and feedback cases. Add a durable layer for human work.
EXISTING INPUTS
Pipeline + store observations
Builds · account health · console feedback · review cases
NEW ADAPTERS
Detect + prepare
Classify dependency · group duplicates · version instructions
↓ One task for the root dependency
PRIVATE REGISTRY
Who / where / allowed
Publisher · role · profile · network · secret references
NEW · ACTION SERVICE
Studio Actions
Inbox → claim → workspace → result
Transactional tasks + events + outbox
SESSION BROKER
Exclusive control
Human ↔ automation
One approved profile at a time
↓ Submitted result + fresh evidence
VERIFIER
Did it actually work?
Correct identity · expected state · current release
EXISTING ENGINE
Resume eligible work
Scheduler rechecks scope → executor → observed result
FRONT ENDCurrent Studio
BACK ENDExisting Node service
NEW TASK STORAGESQLite + event outbox
BROWSEROcto + session broker
Recommended first deployment: existing private Studio. A later Cloudflare Access + Tunnel front door can provide authenticated off-tailnet access. This public report is a separate static site. Cloudflare model ↗
Engineering detail: component ownership, storage and APIs +
The action service owns tasks; the existing scheduler owns pipeline stages. A verified dependency produces a durable event. It never writes a stage directly to “done.” Use atomic claims, event deduplication and reconciliation across the task database and existing file ledgers.
New routes cover list, detail, claim, workspace, results and defer. Only a service-authorized verifier can record a successful check. Preserve current CSRF, origin and access checks. Store files privately with per-object authorization and keep credentials in the secret store.
The current registry contains two fixed store lanes. Generalize it to publisher IDs and action capabilities before scaling to many accounts. Existing resource leases must cover human and automated activity together.
Read the complete contract, state machine and API table →05 / RELIABLE HANDOFFSA click is a report.
A click is a report.
A check is proof.
Two independent questions: did the person finish, and is the system ready to continue?
Ready→Claimed→In progress→Submitted→Verifying→Resolved
History changes.
New challenge? Revise the instructions. New build? Replace the stale upload task. Preserve the previous attempt.
Versioned evidence and success conditionsOnly one driver.
A person and an agent cannot control the same publisher session together. Disconnects revoke access before reassignment.
Shared lease and session reconciliationRecovery survives restarts.
Save the verified outcome and outgoing event together. Deliver again if needed; deduplicate before continuing.
Durable outbox, periodic recovery scanUpload outcome unknown
Inspect the console before replaying the write.
Platform still processing
Show “Waiting for platform” and the next check.
No machine confirmation
Escalate for explicitly labeled authorized attestation.
Owner declined / task expired
Keep affected work blocked; show the reason.
The repository already uses write intents and guards for unknown outcomes. The proposal extends those principles to human work. Existing submission contract ↗
06 / PEOPLE, ACCOUNTS & PLATFORMSOne interface.
One interface.
Different authority.
The person assigned to a task must have the right platform role. Access to the desk alone does not grant it.
Automation
Diagnoses, prepares files, drafts replies, monitors, checks outcomes and resumes authorized work.
Routine work + evidence
Trusted operator
Uses their permitted sessions to upload, complete forms, collect missing facts and follow prepared instructions.
Assigned publisher + scoped access
Account holder
Handles holder-only agreements, identity, recovery and high-impact decisions assigned to them.
Identity + accountable decisions
Some actions require the holder.
Apple documents Account Holder access for paid agreements and possible 2FA during acceptance.
Official agreement guidance ↗Permissions and first-run work matter.
Access can be app-scoped. The Edits API has console prerequisites and does not fill legal consents.
Role permissions ↗ Edits API limits ↗Browser access is a separate layer.
Folder and action permissions depend on team setup and subscription. They do not replace store roles.
Official team capabilities ↗Owner pilot first. The current shared remote desktop is broad access. Delegation needs an isolated profile workspace or a reviewed Octo team setup with store-native user permissions. A limited task card cannot restrict a privileged browser.
Account onboarding, proxies, SMS and evidence +
Keep Studio actor, publisher organization, platform user, Octo profile and network assignment as separate records. Confirm legitimate account control, recovery ownership, supported enrollment or transfer and signing-key custody at onboarding.
Check the approved connection before opening the account. A dead proxy creates a vendor/setup task; it never silently falls back to another publisher or direct network. Browser access and API access have separate health checks. These are project operating rules, not a guarantee that a platform will avoid new challenges.
SMS and passwords go directly into the platform, with capture suspended on credential screens. Keep receipts and redacted evidence; choose document retention before opening access to operators. Some steps still require a trusted phone, desktop or the holder's presence.
Verification may involve official documents and later platform review, depending on the account. Google’s verification guidance for older accounts ↗
07 / THE FEEDBACK LOOPEvery response finds
Every response finds
its way back into the work.
Preserve the original message, app and release. Route the actual problem to the right owner.
STORE / TESTER / PERSON
One feedback case
Original message + evidence + affected version
Fix the product
Reproduce → patch → build → QA → submit within scope
Correct the material
Prepare changes → check against the app → update listing
Create a human task
Explain → correct workspace → person acts → verify
Collect the missing facts
Capture → clarify → revise instructions → assign
↶
Verified recoveries become better instructions. Version the playbook and test the check. Keep uncertainty visible; past success is context, not future authority.
Reuse the existing feedback cases and repair routing. For updates, use supported webhooks, bounded polling and explicit manual capture where coverage is missing. Apple now documents selected build, app-version and tester-feedback webhooks. Apple webhook coverage ↗
08 / PROS, CONS & ALTERNATIVESLess coordination.
Less coordination.
More explicit state.
The system removes the need to reconstruct context. It still depends on people, store behavior and maintained checks.
| Choice | What we gain | What it costs |
|---|---|---|
| Extend Studio | One workflow and release authority | Adapters around existing file ledgers |
| Prepared human tasks | Fewer explanations and context switches | Templates and instructions need upkeep |
| Verify before resuming | Less false completion and duplicate action | Checks can fail or wait on platform latency |
| Approved remote session | Correct publisher context stays together | Remote UX, isolation and device exceptions |
| One task per dependency | One fix can unlock several apps | Dependency and stale-result rules |
| Account holder participation | Actions follow real platform authority | Human availability remains a bottleneck |
Fast to start
Useful fallback. Weak ownership, completion tracking and automatic continuation.
Studio + action service
Reuses what works and adds the missing task, workspace and verification layer.
More infrastructure
A cloud engine or ticket platform still needs the browser broker and outcome checks.
09 / IMPLEMENTATION PLANProve the handoff.
Prove the handoff.
Then add the team.
Start with current Play and Apple publishers. Each phase has observable exit criteria.
Replay the blockers
Confirm roles, sources and five historical cases.
Exit proof Every case has a packet and a success check.
Useful owner inbox
Task storage, grouping, claim, results and private workspace handoff.
Exit proof An owner resolves a rehearsal without chat context.
Verified continuation
Broker ownership, verifiers, durable events and recovery.
Exit proof Restarts and repeat events cannot duplicate a submission.
Delegate + learn
Isolated access, notifications, feedback tasks and playbook review.
Exit proof An operator sees only their permitted publisher.
Planning estimate: roughly 12–20 engineering days for phases 0–3 with one experienced engineer and available account access. Platform waiting time is additional. Re-estimate after the first phase; this is not a delivery commitment.
SUCCESS IS MEASURED INHuman minutes saved.
Human minutes saved.
Verified work resumed.
Active timeMedian / p90 minutes per task
First-pass successVerified without reopening
Recovery qualityDuplicates, stale tasks, resume latency
Acceptance tests and rollout boundaries +
Test duplicate events, competing claims, human/agent session races, restarts, unknown uploads, wrong account, stale builds, expired links, unavailable verifiers, notification failure, role boundaries and evidence access. Rehearse an unknown screen and a rejected release end to end.
Instrument a two-week pilot before setting time-saving targets. Require proof or explicit attestation for every resolved task, and zero duplicate submissions in fault tests.
Keep paused devices paused. Resolving a login cannot start the owner's laptop worker. Feature-flag task creation and continuation separately; preserve the existing CLI and guarded release executor during rollout.
10 / YOUR DECISIONSFour choices shape
Four choices shape
the first version.
Recommended defaults are selected for discussion. Change them and download your notes. Nothing here authorizes or starts work.
REVIEW NOTES
What this report proves.
A proposed product, architecture, tradeoffs and delivery plan grounded in source inspection and official documentation. The task examples are illustrative. The operational system is not built or activated by this report.
Evidence boundaries
Repository baseline: e07eff9. Historical sibling changes are explicitly labeled. Platform documentation checked 10 September 2026. No live account login, proxy repair, legal acceptance, store upload or notification was performed.