# Run from your existing Windows and ChatGPT account

`single-user-local` removes the second Windows-account/VM requirement. It keeps the original queue, signed decisions, Git guards, recovery, locking and finite resource budgets. **Phase 10 and the actual roadmap remain disabled.** The current accepted development baseline is still an explicit policy decision, not something setup infers from main.

## Setup once

From the tooling worktree on `codex/autonomous-roadmap-single-user`:

```powershell
pwsh -NoProfile -File .\scripts\Run-JobjaktBacklog.ps1 -Command setup
. .\scripts\Use-JobjaktBacklog.ps1
Jobjakt status
Jobjakt dry-run
```

Setup detects the current username/SID, Codex, Git, PowerShell, Python and this separate repository worktree. It installs at `$HOME\.jobjakt-backlog\single-user-local`, with an auth-only child directory and a separate task temp directory. This stable home-relative location avoids Codex desktop package LOCALAPPDATA redirection. Use `-Repository <isolated clone/worktree>` and `-ControlRoot <new location>` for explicit paths. A separate clone remains preferable for long-running development, but another Windows identity is unnecessary.

Existing state, prompts, activation policy and authentication are never reset by setup. A disabled, unused single-user installation may refresh the trusted code only; requalify after code changes. An existing dedicated installation remains separate and unchanged. No machine user, VM, paid service, signing key, scheduled task or token is created by basic setup. The optional `init` command retains the older dedicated-runner mode.

In later terminals, load the short command once:

```powershell
. "$HOME\.jobjakt-backlog\single-user-local\Use-JobjaktBacklog.ps1"
Jobjakt status
```

This adds a function to that terminal only. It does not edit your normal PowerShell profile or Codex configuration. If you selected a custom ControlRoot, invoke its `Run-JobjaktBacklog.ps1` directly with `-Command`; it detects its own installed directory.

## Sign into the same ChatGPT account

Run this yourself in a real PowerShell terminal:

```powershell
Jobjakt auth
Jobjakt auth-status
```

Choose the **same ChatGPT account you already use** in the browser login. This is a new local login session to the same service account, not a second subscription. Authentication is forced to ChatGPT with file storage in the dedicated CODEX_HOME. No API-key login, access-token piping or copying of `auth.json` is performed. `auth-status` reports the authentication kind without printing credentials; the controller cannot establish that two human-selected accounts are the same merely from a directory name. Actual successful sign-in remains a human step; it was not done by this implementation task.

Normal authentication/config reuse is deliberately not offered: the normal home may contain unrelated plugins, servers, rules and credentials. An auth-only home plus explicit capability restrictions avoids inheriting that configuration. Account quotas/rate limits remain those of your existing account; no new subscription or usage allowance is promised.

## Signing key and real qualification

These operator actions require your interactive terminal and no active controller worker:

```powershell
Jobjakt key
Jobjakt qualify
```

`key` creates a nonexportable RSA owner certificate in **your current Windows user** certificate store, exports only its public certificate to ControlRoot, and pins its hash/thumbprint/SID. It does not replace an existing configured key. It grants no roadmap authority. The private key is never written to the repository or copied between accounts.

`qualify` launches only trusted synthetic probes through native MXC. It first proves canaries and keys are usable from the trusted operator context, then checks the worker cannot read/open for writing protected configuration, approvals, a signing-key file canary, normal Codex data, personal-file canaries, an unrelated-repository canary or synthetic production credentials. It tests denied socket access against a real listening loopback port and attempts certificate/CNG signatures with a temporary same-user key. When your actual owner key is configured, the exact pinned key also needs a host-positive and worker-negative signing test. No real production credential, personal document, external endpoint or model is used. Synthetic certificates/files are cleaned up; any cleanup failure blocks qualification.

Results are saved at `qualification.json`, including scope, binding, issue time and actual owner-key disposition. **A canary PASS alone is not unattended approval.** Missing owner key, incomplete/failed/stale probes or changed configuration keeps the controller paused. Qualification expires after 24 hours, and start rechecks native boundaries. The stock legacy sandbox's earlier CryptUnprotectData failure was not bypassed: this mode explicitly selects the [documented MXC implementation](https://learn.chatgpt.com/docs/windows/windows-sandbox) and refuses fallback. Its deny/read/write rules use the supported [permission-profile format](https://learn.chatgpt.com/docs/permissions).

After reviewing a successful qualification of your real key, you can select the runtime policy:

```powershell
Jobjakt enable-unattended
```

This requires your typed confirmation, but still does **not** enable the queue or authorize Phase 10. The enabled manifest, environment grant, roadmap grant and exact phase entry approvals remain independently signed through the existing `configure` workflow. Do not perform that activation until current Pre-Phase-10 acceptance and publication are finished and you explicitly approve Phase 10 entry.

If the native boundaries cannot be enforced, use the default `operator-controlled` policy. `start`/`resume` cannot launch autonomous workers under that policy. You can inspect status/logs/requests and use `prepare` to generate a protected inspection-only checkpoint brief. This is a deliberate execution pause, not an unsandboxed “interactive” fallback. Resolve the precise boundary or use an independently protected approval/execution mechanism before allowing untrusted automation.

## Routine commands

```powershell
Jobjakt validate
Jobjakt dry-run
Jobjakt status
Jobjakt current
Jobjakt logs
Jobjakt start                       # only after qualified runtime and separately signed phase activation
Jobjakt pause
Jobjakt resume
Jobjakt retry -Stage PHASE-10
Jobjakt recover
Jobjakt approve
```

`approve` shows the exact pending JSON request and requires a typed challenge, an explicit Approve/Revise/Reject disposition and your concrete decision text. It signs with the pinned owner key. It holds the repository lock and refuses active workers. A worker subprocess has no terminal input and cannot use the key when qualification is valid. A JSON file claiming approved remains invalid.

For homepage decisions, choose elements or revisions in the decision text. `Revise` reruns that checkpoint; final `Approve` advances after all gates pass. Product scope, provider rights, translation review, material security decisions and release evidence retain their gates. There is no automatic deployment or main merge path.

For an interrupted run: inspect the recorded process tree, run `recover` to create its exact request, run `approve` after confirming the tree is gone, then `recover` again and `resume`. Only the recovery request can be signed while recovery-required is set. A live recorded PID or an unverifiable PID marker still blocks signing. Never kill a reused PID blindly. Signing alone does not clear recovery-required. Publication failures reuse the exact verified local commit; no model rerun or force push is needed.

## Overnight and scheduling

The controller works without its GUI remaining open. A qualified run can continue with the desktop **locked**, provided the existing user session, dedicated authentication and signing provider are available and the PC is awake. No lock, sleep, firewall or elevation setting is changed. Logging out is different from locking: unattended execution before login requires you to configure the existing account's batch credentials/profile in Windows Task Scheduler and qualify that actual context. This implementation does not collect or store your Windows password.

Optional task definition, after real qualification:

```powershell
pwsh -NoProfile -File .\scripts\Register-JobjaktBacklogTask.ps1
# Review its preview, then explicitly register:
pwsh -NoProfile -File .\scripts\Register-JobjaktBacklogTask.ps1 -Install
```

It uses your existing login, limited privileges, logon plus 15-minute continuation, an eight-hour task limit and no overlapping instances. Scheduled continuation uses `start`, preserving a manual pause; `resume` is the owner's deliberate unpause. The registration script refuses unqualified runtime/key state. No task was registered by this work.

## Security difference and current handoff

Real canaries verify the tested native-worker boundaries. They are not an exhaustive proof against every Windows API, credential provider or future sandbox defect. Unrestricted applications running under your same Windows identity are outside the worker boundary and can still act as you. This is not equivalent to an independently administered account/VM. Apps, plugins, MCP and web search remain disabled in this mode; a later security scan/provider task needing them must pause for independently qualified capabilities, not silently enable your normal configuration.

At handoff: setup and canary qualification have been exercised under the current login; the dedicated home is **not signed in**, the real owner key is **not configured**, operation is **operator-controlled**, and the queue is **disabled**. See [acceptance and evidence](SINGLE_USER_ACCEPTANCE.md). Your next steps are the same-account `auth`, operator `key`, and real-key `qualify` commands; actual roadmap activation still waits for formal Phase 10 entry.