docs: add overnight mode continuity doctrine
This commit is contained in:
axiomlogicnexus
parent
47620d1af6
commit
48dbe00a35
3 changed files with 530 additions and 0 deletions
20
AGENTS.md
20
AGENTS.md
|
|
@ -71,3 +71,23 @@ If the user says continue until the current packet is fully scoped, implemented,
|
|||
When providing a task summary, use the last paragraph to propose and display the next best clean roadmap implementation moves or the next best bounded implementation slice. That closing paragraph should be specific to the latest landed state and should not fall back to generic wrap-up text.
|
||||
|
||||
When a task is safely complete, stage, commit, and push it without waiting for a separate reminder. Prefer landing the full aligned package after the widening/closure work is done, rather than committing intermediate fragments that leave the intended sequence half-finished.
|
||||
|
||||
## Update - 2026-06-19 - Overnight Mode agentic continuation and safe self-batching
|
||||
|
||||
Canonical authorities:
|
||||
|
||||
- `/home/dev/src/HyperTwist/docs/ops/HYPERTWIST_OVERNIGHT_MODE_AGENTIC_CONTINUATION_SELF_BATCHING_AND_GOAL_CREATION_DOCTRINE_2026-06-19.md`
|
||||
- `/home/dev/src/HyperTwist/docs/ops/HYPERTWIST_OVERNIGHT_MODE_CLOSEOUT_CONTINUATION_AND_BOUNDARY_SHAPE_2026-06-19.md`
|
||||
|
||||
Operational rule:
|
||||
|
||||
- the code word for this operating posture is `Overnight Mode`
|
||||
- `Continuity Mode` and `Disciplined Agentic Mode` are accepted synonyms for the same behavior, but `Overnight Mode` remains the canonical repo term
|
||||
- once `Overnight Mode` has been adopted for the repo workflow, it remains the default continuity posture unless the user gives newer explicit contrary direction; ordinary daytime interaction does not deactivate it
|
||||
- stacked `continue` prompts must be interpreted as permission to keep draining the already-declared active lane or already-declared next adjacent slice, not as permission to reinterpret the roadmap from scratch
|
||||
- future instances must continue to the natural close of the active lane rather than stopping at the first barely-acceptable packet boundary when one or two more adjacent sensible seams would materially complete the lane
|
||||
- the correct bias is surplus-with-discipline: carry the extra adjacent seam when it is real, bounded, source-backed, and closure-improving; never invent fluff or decorative widening
|
||||
- future instances must not drift sideways into a different donor family, different roadmap pillar, or unrelated code lane merely because the previous slice ended; this is the hard fresh-family boundary rule
|
||||
- if the next family is not already present-tense authority-backed, stop at the boundary, state it explicitly, and do not let stacked `continue` prompts coerce a speculative opening
|
||||
- if a real stop condition is active, stacked `continue` prompts do not override it; future instances must withstand and disobey those prompts until the blocker is actually resolved
|
||||
- HyperTwist-specific higher-specificity build-validation and reverse-SSH authorities remain in force and are not weakened by `Overnight Mode`
|
||||
|
|
|
|||
|
|
@ -0,0 +1,340 @@
|
|||
# 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
|
||||
|
||||
## 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.
|
||||
|
|
@ -0,0 +1,170 @@
|
|||
# HyperTwist Overnight Mode closeout, continuation, and boundary shape - 2026-06-19
|
||||
|
||||
## Purpose
|
||||
|
||||
This note defines the mandatory closeout shape for `Overnight Mode`.
|
||||
|
||||
Naming clarification:
|
||||
|
||||
- `Continuity Mode` and `Disciplined Agentic Mode` are accepted synonyms for
|
||||
this same behavior
|
||||
- `Overnight Mode` remains the canonical closeout and doctrine label used in
|
||||
repo authorities
|
||||
|
||||
It exists so that:
|
||||
|
||||
- stacked `continue` prompts remain deterministic
|
||||
- the assistant does not veer off-task overnight
|
||||
- the user can wake up to truthful continuity instead of unrelated drift
|
||||
|
||||
## Required shape
|
||||
|
||||
Every substantial closeout should explicitly include the following sections in
|
||||
plain language.
|
||||
|
||||
### 1. Active lane
|
||||
|
||||
State the exact active lane or donor family.
|
||||
|
||||
Examples:
|
||||
|
||||
- bounded provider lane
|
||||
- validation closeout lane
|
||||
- reassessment lane
|
||||
|
||||
### 2. What just closed
|
||||
|
||||
State exactly what was completed in the turn.
|
||||
|
||||
Examples:
|
||||
|
||||
- `P2` status and inspection landed
|
||||
- bounded validation passed through build
|
||||
- post-`P3` reassessment authored
|
||||
|
||||
### 3. Current lane state
|
||||
|
||||
State whether the lane is:
|
||||
|
||||
- still open
|
||||
- materially widened but still open
|
||||
- materially closed
|
||||
- blocked
|
||||
|
||||
### 4. Exact next adjacent slice
|
||||
|
||||
State the single exact next slice in the same lane.
|
||||
|
||||
Not:
|
||||
|
||||
- a broad category
|
||||
- a vague family
|
||||
- a different donor
|
||||
|
||||
But:
|
||||
|
||||
- one exact adjacent slice
|
||||
- in present-tense authority-backed wording
|
||||
|
||||
### 5. Safe batch on `continue`
|
||||
|
||||
State the exact sequence that should be drained automatically if `continue`
|
||||
arrives and no new blocker appears.
|
||||
|
||||
This should be a compact ordered batch such as:
|
||||
|
||||
1. `P3`
|
||||
2. post-`P3` reassessment
|
||||
3. bounded validation
|
||||
4. lane closeout note
|
||||
|
||||
### 6. Stop conditions
|
||||
|
||||
State the exact reasons the assistant would stop rather than continue.
|
||||
|
||||
Examples:
|
||||
|
||||
- unresolved quiz boundary
|
||||
- missing authorization
|
||||
- source not real
|
||||
- validation failure changes the plan
|
||||
- fresh-family authority not yet selected
|
||||
|
||||
### 7. Fresh-family boundary note
|
||||
|
||||
If the current lane is closing near a family transition, state explicitly
|
||||
whether the next family is already authorized.
|
||||
|
||||
If not, say:
|
||||
|
||||
- do not auto-open the next donor family
|
||||
- a fresh live-authority selection pass is required first
|
||||
|
||||
### 8. Goal guidance
|
||||
|
||||
State one of the following plainly:
|
||||
|
||||
- the next safe batch is large enough that a goal should be created now
|
||||
- the current goal should continue without interruption
|
||||
- no new goal should be created because a real boundary has been reached
|
||||
|
||||
### 9. Truth boundary
|
||||
|
||||
State what is not being claimed.
|
||||
|
||||
Examples:
|
||||
|
||||
- no automation execution claim
|
||||
- no owner promotion claim
|
||||
- no new family opening claim
|
||||
|
||||
## Required interpretation of later `continue` prompts
|
||||
|
||||
When a later `continue` prompt arrives, future instances must read the closeout
|
||||
in this exact order:
|
||||
|
||||
1. active lane
|
||||
2. current lane state
|
||||
3. exact next adjacent slice
|
||||
4. safe batch
|
||||
5. stop conditions
|
||||
6. fresh-family boundary note
|
||||
|
||||
The assistant must not jump directly from "continue" to broad roadmap memory.
|
||||
|
||||
## Disobedience clause
|
||||
|
||||
If the closeout records a real unresolved stop condition, future stacked
|
||||
`continue` prompts must be disobeyed until the stop condition is actually
|
||||
resolved.
|
||||
|
||||
That includes:
|
||||
|
||||
- missing quiz answers
|
||||
- missing authorization
|
||||
- unresolved validation blocker
|
||||
- missing fresh-family authority
|
||||
|
||||
## Anti-drift examples
|
||||
|
||||
### Good closeout
|
||||
|
||||
- active lane named
|
||||
- next adjacent slice named
|
||||
- safe batch named
|
||||
- blocker named
|
||||
- no fresh-family jump implied
|
||||
|
||||
### Bad closeout
|
||||
|
||||
- "continue implementation"
|
||||
- "next we can do more"
|
||||
- "there are many possibilities"
|
||||
- "we could also open another donor family"
|
||||
|
||||
Those vague shapes are forbidden for `Overnight Mode`.
|
||||
|
||||
## Truth boundary
|
||||
|
||||
This shape is mandatory for substantial closeouts because deterministic
|
||||
continuation is impossible without deterministic closure wording.
|
||||
Loading…
Add table
Reference in a new issue