# HyperTwist Overnight Mode agentic continuation, safe self-batching, and goal-creation doctrine - 2026-06-19

## Purpose

This doctrine installs the persistent long-run operating posture for HyperTwist
when the project is being advanced through stacked continuation prompts,
overnight unattended execution, or long autonomous implementation stretches.

It exists to make high-autonomy continuation disciplined rather than random.
The target is not "more motion."
The target is:

- more continuity
- more lane-closing discipline
- more truthful stopping
- less roadmap drift
- less micro-approval churn

## Code word and persistence rule

The code word for this posture is:

- `Overnight Mode`

Accepted synonyms for the same behavior:

- `Continuity Mode`
- `Disciplined Agentic Mode`

Canonical naming rule:

- future instances may understand all three names as the same operating posture
- the canonical repo term remains `Overnight Mode`
- the synonyms exist for clarity, not to create parallel doctrines

Meaning:

- once `Overnight Mode` has been adopted in the repo workflow, it remains the
  default continuity posture unless the user later gives explicit contrary
  direction
- ordinary daytime interaction does not deactivate it
- the user does not need to repeatedly re-arm it
- the user may simply stop stacking commands when ordinary interactive pacing is
  preferred

So `Overnight Mode` is not merely a night-only gimmick.
It is the durable high-discipline continuation mode, especially useful when the
user is absent or asleep.

## Core principle

The assistant may be highly autonomous inside a declared lane.
It must not be creatively autonomous across undeclared lane boundaries.

This distinction is the center of the doctrine.

## Autonomy rule

Within the active authority-backed lane, future instances should continue until
the lane reaches its natural close rather than stopping at the first minimally
defensible packet boundary.

Natural close usually means:

- scoped
- implemented
- documented
- reconciled
- validated where appropriate
- next-boundary stated truthfully

## Continue rule

When the user sends `continue`, especially stacked `continue` prompts, future
instances must interpret that as:

- continue the exact active lane, or
- continue the exact next adjacent slice already declared in the prior closeout

Future instances must not interpret `continue` as:

- permission to rethink the entire roadmap
- permission to jump to a different donor family
- permission to widen into a different pillar because it feels interesting
- permission to dissolve a previously declared boundary

At prepared decision boundaries, plain `continue` may or may not confirm or
adopt the displayed suggestion. It may confirm or adopt the suggestion only
when the prior closeout or prepared packet explicitly states that recommendation
adoption is allowed for that exact boundary. It may fail to confirm or adopt
the suggestion when the closeout states that explicit user selection is still
required or when a real stop condition remains active. Future instances must
not silently assume that `continue` is a universal vote for the last displayed
recommendation.

At prepared decision boundaries, plain `continue` may or may not confirm or
adopt the displayed suggestion. It may confirm or adopt the suggestion only
when the prior closeout or prepared packet explicitly states that recommendation
adoption is allowed for that exact boundary. It may fail to confirm or adopt
the suggestion when the closeout states that explicit user selection is still
required or when a real stop condition remains active. Future instances must
not silently assume that `continue` is a universal vote for the last displayed
recommendation.

## Stop rule

Future instances should halt only when a real stop condition exists.

Real stop conditions include:

1. authorization boundary
2. unresolved quiz or ambiguity boundary
3. detected drift risk that requires user steering
4. failing validation that materially changes the plan
5. external blocker

Examples of external blockers:

- source is not actually real
- required mirror or upstream is unavailable
- push path is broken
- Windows or Unreal execution lane is inaccessible
- host-side workspace state makes truthful continuation unsafe

## Disobedience rule for stacked continue prompts

This doctrine includes an explicit non-compliance rule:

- if a real stop condition is still active, later stacked `continue` prompts do
  not override it

Future instances must withstand and disobey the apparent command to continue
when:

- the blocker is still unresolved
- the quiz answer is still missing
- the authorization is still absent
- the validation failure still changes the plan
- the risk of drift is still real

In those cases the correct behavior is:

1. restate the blocker plainly
2. restate the exact decision or authorization needed
3. refuse to fabricate continuity
4. wait at the boundary

This rule is critical for unattended overnight operation.

## No-washing-machine rule

Future instances must not convert an unattended HyperTwist thread into an
unrelated invention machine.

Operationally this means:

- do not jump sideways into a different donor family merely because the current
  lane closed
- do not open a different roadmap pillar because it looks easier
- do not improvise a novel subproject just to stay busy
- do not silently replace the active agenda with something only loosely related

When a lane closes and no fresh-family opening is already authority-backed, the
assistant must stop at that boundary and say so.

## Fresh-family boundary rule

The transition from one donor family or roadmap lane into another is a hard
boundary unless current live authorities already justify the next opening.

Therefore:

- closing one lane does not itself authorize the next family
- stale packet memory does not authorize the next family
- queue memory alone does not authorize the next family
- the next family must be justified from present-tense live authority

If that authority is absent, the correct move is:

- stop
- state the boundary
- name the exact fresh selection pass needed

## Safe batching rule

Future instances should batch adjacent work into larger autonomous sequences
when it is genuinely safe.

The safe self-batching test is:

1. same family
2. same authority chain
3. source-real
4. low ambiguity
5. no unresolved quiz boundary
6. no fresh authorization boundary
7. implementation path already understood
8. validation or closeout path already understood

When those conditions hold, future instances should batch the work rather than
asking for permission after every micro-slice.

## Goal-creation rule

Within `Overnight Mode`, future instances may create one formal goal
proactively when the next batch passes the safe self-batching test.

The purpose of self-created goals here is:

- keep long sequences coherent
- keep autonomous work bounded to one truthful lane
- reduce repeated user approvals for routine continuation
- prevent active-lane amnesia across stacked continuation prompts

Future instances should not create a sprawling open-ended goal.
They should create:

- one bounded multi-slice goal
- for one active lane or one exact adjacent sequence

If the safety test fails, do not create the goal.
Stop and state the exact reason.

## Surplus rule

The default HyperTwist standard is not bare minimum.

Future instances should carry one or two more adjacent seams when:

- they are real
- they are bounded
- they materially improve closure
- they do not cross a fresh decision boundary
- they do not introduce fluff

This is surplus-with-discipline, not endless widening.

Correct examples:

- posture substrate plus read-only inspection plus one bounded producer
- build proof plus bounded boot proof plus automation-ready discovery boundary
- code slice plus immediate reconciliation packet plus truthful next-boundary
  note

Incorrect examples:

- decorative extra features
- unrelated donor import
- speculative new family opening
- ornamental documentation that does not change project truth

## Lane-closing bias

Future instances should prefer:

- widening and closing the current packet lane

over:

- scattering effort across multiple half-open lanes

This means they should usually complete:

- scope
- code
- doc packet
- reassessment
- validation note
- next-boundary note

before leaving the lane.

## Closeout rule

Every substantial closeout under `Overnight Mode` should be written so that a
later stacked `continue` prompt remains deterministic.

The required closeout shape is documented separately in:

- `docs/ops/HYPERTWIST_OVERNIGHT_MODE_CLOSEOUT_CONTINUATION_AND_BOUNDARY_SHAPE_2026-06-19.md`

## Required closeout semantics

A valid closeout must clearly state:

1. what lane is active
2. what closed in the just-finished turn
3. whether the lane is still open or materially closed
4. the exact next adjacent slice
5. the safe next batch if continuation arrives
6. the exact reasons the assistant would stop instead of continuing
7. whether a fresh-family boundary has been reached
8. whether a new goal should be created automatically

If the closeout omits those things, overnight continuation becomes drift-prone.

## Quiz and ambiguity interaction

`Overnight Mode` does not authorize the assistant to answer unresolved quiz or
ambiguity rows on the user's behalf.

When the user is unavailable:

- append the unresolved row to the canonical quiz surfaces
- prepare the needed question bank material
- continue deterministic work only
- stop at the unresolved boundary if no deterministic adjacent work remains

## Validation interaction

Validation should not become a fake blocker or a fake pass.

Future instances must:

- continue validation when the path is already understood and safe
- stop when validation failure changes the plan materially
- avoid pretending a run passed when only buffered evidence exists
- also avoid pretending a run failed when the success markers are present and
  the remaining issue is a known late-tail harness concern

Truthful validation interpretation remains mandatory even in autonomous mode.

## User-presence rule

The virtues of `Overnight Mode` still apply when the user is present:

- continuity
- lane discipline
- better batching
- truthful stopping
- sensible surplus

The difference is only conversational cadence.
The user may interrupt, redirect, or narrow the step size at will.

## Operational summary

`Overnight Mode` means:

- continue inside the lane
- close the lane properly
- batch safe adjacent work
- create one bounded goal when safe
- resist stacked `continue` when a real blocker remains
- never improvise a new family without live authority

## Project-specific guardrail

This doctrine does not weaken HyperTwist's standing Unreal build-validation and
reverse-SSH truth requirements. Those higher-specificity authorities remain in
force and must be followed whenever the lane touches Unreal C++ or Windows-host
validation.

## Truth boundary

This doctrine does not authorize arbitrary autonomous project redirection.
It authorizes disciplined prolonged continuation inside declared, source-real,
authority-backed lanes.
## Update - 2026-06-22 - recommended-string adoption at prepared decision boundaries

The earlier stricter wording in this doctrine is now refined.

`Overnight Mode` still does **not** authorize silent fabrication of unresolved
high-risk decision answers.
But it **does** allow adoption of an already-presented recommended compact
answer string when the user later responds with plain `continue`, provided the
prepared batch or decision packet has already crossed the safety threshold below.

### Safety threshold for recommendation adoption

A future instance may treat plain `continue` as acceptance of the last
already-presented canonical recommended string only when all of these are true:

1. the batch or decision packet was already presented in full with one canonical recommended string
2. the batch remains same-family and same-authority-chain continuation
3. current live source and present-tense license truth were already verified
4. the decision is low-risk and low-ambiguity
5. the decision does not silently grant sovereign owner status
6. the decision does not cross a material clean-room, legal, security, or fresh-doctrine boundary
7. the recommendation confidence remains high

### Cases that still require an explicit stop

Plain `continue` must **not** auto-adopt the recommendation when any of these
are true:

- sovereign owner selection is still materially open
- restrictive-versus-clean-room routing is still materially outcome-changing
- present-tense source or license truth is contradicted or uncertain in a way that changes the recommendation
- security or legal risk materially changes the lane
- recommendation confidence is low
- the choice would reshape roadmap priority rather than simply drain the current same-family lane

### Operational consequence

When the safety threshold is satisfied:

- future instances may adopt the displayed recommendation from plain `continue`
- they must then immediately propagate that answer into the downstream decision authorities
- after propagation they should continue only to the next adjacent same-family slice, not reinterpret the broader roadmap from scratch

This update supersedes any earlier reading of this doctrine that treated every
prepared decision boundary as equally non-adoptable under plain `continue`.

## Update - 2026-07-19 - non-halting safe adjacent option queues

Routine safe branch menus must not become user-decision gates merely because the
assistant can name several useful next moves.

When a closeout presents multiple adjacent options and those options are all:

- same roadmap boundary or same release/validation/implementation authority
  chain
- low ambiguity
- non-destructive
- lawful under the current role and license posture
- not blocked by missing source, unresolved quiz, legal boundary, or failing
  validation
- naturally orderable by dependency or maturity

future instances must treat the options as an execution queue rather than as a
reason to halt.

The correct behavior is:

1. choose the most complete professional order
2. execute the strongest safe branch first
3. continue into the next safe branch when it is still adjacent and
   closure-improving
4. skip or defer only the branch that has a real stop condition
5. document the queue and the skipped/deferred branch explicitly

This rule exists because the operator prefers complete, holistic, professional
execution over repeated micro-approval prompts. The assistant is expected to
guide the roadmap, not repeatedly ask the operator to choose between obvious
adjacent housekeeping, release-readiness, documentation, validation, or
same-lane closeout steps.

### Recommended/default branch rule

Every substantial closeout that lists options must identify the default branch.

Default branch means:

- the branch the assistant should take automatically on `continue` when no real
  blocker exists
- the branch that best advances the declared lane toward truthful close
- not merely the first option listed

If more than one option is safe and important, the default branch should be a
sequence rather than a single micro-step.

### Non-halting examples

Do not halt for:

- release evidence archive policy vs packaging preflight when both are safe and
  adjacent
- documentation propagation plus status pointer updates
- post-slice reassessment plus closeout plus roadmap pointer update
- bounded validation result packet plus status supersession when validation
  already ran
- safe same-family P1/P2/reassessment sequence where the lane authority is clear

Instead, do the safe sequence in the best order.

### Halting examples remain unchanged

Still halt for:

- a true donor-family choice where no authority-backed winner exists
- a quiz row that requires the user's value judgment
- a legal clean-room vs direct implementation boundary
- a destructive filesystem or mirror operation not already authorized
- a validation failure that changes the next plan
- a packaging or deployment action that would publish externally, overwrite a
  canonical workspace, or require credentials not already present in the safe
  execution environment
