Prepare v0.6.9 sustained auto loop release

README.md

@@ -21,7 +21,7 @@ If `plan.md` has a `Target Stage`, plain `hyper run` keeps moving packet by pack
 
 The goal is simple: start from a tiny MVP and keep upgrading it until it can behave like a real service, without every AI session losing the project thread.
 
-Current release: `v0.6.7`. It can continue packet by packet toward a target stage, stop and write review notes when evidence is weak, require approval before changing stages, compare Service Quality work against category references, verify release downloads, and recover stale stage state with `hyper migrate`.
+Current release: `v0.6.9`. It can continue packet by packet toward a target stage, stop and write review notes when evidence is weak, require approval before changing stages, compare Service Quality work against category references, verify release downloads, and recover stale stage state with `hyper migrate`.
 
 ## First Run
 
@@ -221,7 +221,7 @@ The same planned action and guard are printed in the CLI output after packet com
 
 `Target Stage` means Hyper Run keeps going until that stage's readiness proof is complete, not merely until `plan.md Current Stage` has that name. For example, `Target Stage: Service Quality` continues into Service Quality packets until validation, operations, benchmark, satisfaction, maintainability, and active-quality evidence are good enough for the Service Quality gate.
 
-When the target proof is complete, plain `hyper run` stops by design. To keep going, raise `Target Stage`, remove it for manual packets, or run an explicit higher `--until` target.
+When a finite target proof is complete, plain `hyper run` stops by design. `Sustained Service Quality` is different: it is an ongoing operating target, so Hyper Run keeps planning focused quality packets until a guard, blocker, approval boundary, repeated no-progress signal, or user decision stops the loop. For finite targets, raise `Target Stage`, remove it for manual packets, or run an explicit higher `--until` target to keep going.
 
 In Codex Desktop you can use the same idea as a project command:
 

README_ko.md

@@ -21,7 +21,7 @@ hyper run
 
 목표는 단순합니다. 작은 MVP에서 시작해, AI 세션이 바뀌어도 문맥을 잃지 않고 실제 서비스처럼 다룰 수 있는 수준까지 계속 개선하는 것입니다.
 
-현재 릴리즈는 `v0.6.7`입니다. 목표 stage까지 packet 단위로 이어가고, evidence가 약하면 멈춰서 review를 남기며, stage 변경은 사용자가 승인할 때만 적용합니다. Service Quality에서는 비슷한 reference와 비교할 수 있고, 설치/업데이트를 검증하며, 오래된 stage 상태는 `hyper migrate`로 복구합니다.
+현재 릴리즈는 `v0.6.9`입니다. 목표 stage까지 packet 단위로 이어가고, evidence가 약하면 멈춰서 review를 남기며, stage 변경은 사용자가 승인할 때만 적용합니다. Service Quality에서는 비슷한 reference와 비교할 수 있고, 설치/업데이트를 검증하며, 오래된 stage 상태는 `hyper migrate`로 복구합니다.
 
 ## 첫 실행
 
@@ -221,7 +221,7 @@ packet 완료나 stage advancement 이후 CLI 출력에도 같은 planned action
 
 `Target Stage`는 `plan.md Current Stage` 이름이 그 단계가 되는 순간을 뜻하지 않습니다. 그 단계의 readiness proof가 완료될 때까지 계속한다는 뜻입니다. 예를 들어 `Target Stage: Service Quality`는 Service Quality packet 안에서도 validation, operations, benchmark, satisfaction, maintainability, active-quality evidence가 충분해질 때까지 계속 진행합니다.
 
-target proof가 완료되면 plain `hyper run`은 의도적으로 멈춥니다. 계속 진행하려면 `Target Stage`를 더 높이거나, manual packet을 위해 제거하거나, 더 높은 `--until` target을 명시하세요.
+유한한 target proof가 완료되면 plain `hyper run`은 의도적으로 멈춥니다. `Sustained Service Quality`는 다릅니다. 계속 운영하는 목표이므로 guard, blocker, 승인 경계, 반복된 무진전 신호, 사용자 결정이 멈출 때까지 focused quality packet을 계속 계획합니다. 유한한 target에서 계속 진행하려면 `Target Stage`를 더 높이거나, manual packet을 위해 제거하거나, 더 높은 `--until` target을 명시하세요.
 
 Codex Desktop에서는 프로젝트 명령처럼 사용할 수 있습니다.
 

docs/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 ## Unreleased
 
+## v0.6.9 - 2026-06-19
+
+- Treat `Sustained Service Quality` as an ongoing operating target so a plan target at that stage keeps planning focused quality packets instead of stopping as target-proof-complete.
+- Set this repository's `plan.md Target Stage` to `Sustained Service Quality` and document the autonomous service-quality operating loop, including continue/stop rules and validator promotion boundaries.
+- Update English and Korean README release wording and target-stage guidance so finite targets still stop on proof completion while sustained service-quality operation continues through guarded packets.
+- Add regression coverage for sustained target continuation while preserving finite target stop behavior.
+
 ## v0.6.8 - 2026-06-18
 
 - Keep the normal human flow centered on `hyper run` by describing `hyper complete` as the agent finish gate and manual recovery command across README, status, doctor, run-blocking, repair, advance, migrate, resume, and generated Codex routing output.

docs/CHANGELOG_ko.md

@@ -2,6 +2,13 @@
 
 ## Unreleased
 
+## v0.6.9 - 2026-06-19
+
+- `Sustained Service Quality`를 계속 운영하는 target으로 처리해, 해당 stage를 plan target으로 둔 경우 target-proof-complete로 멈추지 않고 focused quality packet을 계속 계획하게 했습니다.
+- 이 저장소의 `plan.md Target Stage`를 `Sustained Service Quality`로 설정하고, autonomous service-quality operating loop의 continue/stop 규칙과 validator promotion 경계를 문서화했습니다.
+- 영어/한국어 README의 현재 릴리즈 표기와 target-stage 안내를 갱신했습니다. 유한한 target은 proof 완료 시 멈추고, sustained service-quality 운영은 guard가 있는 packet으로 계속 이어집니다.
+- sustained target continuation을 보호하는 회귀 테스트를 추가하고, 유한한 target stop 동작은 유지했습니다.
+
 ## v0.6.8 - 2026-06-18
 
 - 일반 사용자의 흐름을 `hyper run` 중심으로 유지하도록 README, status, doctor, run-blocking, repair, advance, migrate, resume, 생성된 Codex routing 출력에서 `hyper complete`를 agent finish gate 및 수동 복구 명령으로 설명하게 했습니다.

internal/app/main_test.go

@@ -2709,12 +2709,14 @@ func TestRunAutoUntilSustainedQualityPromotesActiveValidator(t *testing.T) {
 		t.Fatalf("status failed: %v", err)
 	}
 	assertContains(t, status.Stdout, "Stage: Sustained Service Quality")
-	assertContains(t, status.Stdout, "Plan: stop")
-	assertContains(t, status.Stdout, "Next: hyper status --short")
-	assertContains(t, readFile(t, filepath.Join(root, ".hyper", "next-packet.md")), "Action: stop")
+	assertContains(t, status.Stdout, "Plan: run")
+	nextPlan := readFile(t, filepath.Join(root, ".hyper", "next-packet.md"))
+	assertContains(t, nextPlan, "Mode: auto until Sustained Service Quality")
+	assertContains(t, nextPlan, "Action: run")
+	assertContains(t, nextPlan, "Continue automatically by running the command above")
 }
 
-func TestPlanTargetStageToSustainedQualityStopsAfterSustainedProof(t *testing.T) {
+func TestPlanTargetStageToSustainedQualityKeepsPlanningAfterSustainedEntry(t *testing.T) {
 	root := t.TempDir()
 	writeFile(t, filepath.Join(root, "plan.md"), strings.Join([]string{
 		"# Product Plan",
@@ -2820,23 +2822,23 @@ func TestPlanTargetStageToSustainedQualityStopsAfterSustainedProof(t *testing.T)
 	}
 	assertContains(t, advance.Stdout, "Stage advanced: Service Quality -> Sustained Service Quality")
 	assertContains(t, advance.Stdout, "Run target after advance: Sustained Service Quality (plan.md Target Stage)")
-	assertContains(t, advance.Stdout, "Planned action: stop")
-	assertContains(t, advance.Stdout, "Next action: hyper status --short")
-	assertContains(t, advance.Stdout, "Continuation guard: Run-until target proof is complete. Raise or remove `plan.md` Target Stage before starting more work.")
+	assertContains(t, advance.Stdout, "Planned action: run")
+	assertContains(t, advance.Stdout, "Next action: hyper run 'Run active quality checks and reduce one small operational, validation, or maintainability friction for Plan Target Sustained CLI.'")
 	assertNotContains(t, advance.Stdout, "--auto --until")
 	nextPlan = readFile(t, filepath.Join(root, ".hyper", "next-packet.md"))
 	assertContains(t, nextPlan, "Mode: auto until Sustained Service Quality")
-	assertContains(t, nextPlan, "Action: stop")
-	assertContains(t, nextPlan, "Run-until target proof is complete.")
+	assertContains(t, nextPlan, "Action: run")
+	assertContains(t, nextPlan, "Command: hyper run 'Run active quality checks and reduce one small operational, validation, or maintainability friction for Plan Target Sustained CLI.'")
 
 	out, err = runCLI(args("run"), testRoot(root), fakeUpdater{})
 	if err != nil {
-		t.Fatalf("target complete run should stop cleanly: %v", err)
+		t.Fatalf("sustained target run should continue cleanly: %v", err)
 	}
-	assertContains(t, out.Stdout, "Run-until target proof complete: Sustained Service Quality")
-	assertContains(t, out.Stdout, "No runtime packet created.")
-	if exists(filepath.Join(root, ".hyper", "goals", "GOAL-0002")) {
-		t.Fatal("complete sustained plan target must not create another runtime packet")
+	assertContains(t, out.Stdout, "Runtime packet: GOAL-0002")
+	assertContains(t, out.Stdout, "Run mode: auto until Sustained Service Quality")
+	assertContains(t, out.Stdout, "Run target source: plan.md Target Stage")
+	if !exists(filepath.Join(root, ".hyper", "goals", "GOAL-0002")) {
+		t.Fatal("sustained plan target should keep creating focused quality packets")
 	}
 }
 

internal/app/next_packet.go

@@ -315,6 +315,9 @@ func runUntilReached(state projectState, readiness readinessState) bool {
 }
 
 func targetStageProofComplete(target string, readiness readinessState) bool {
+	if normalizeRuntimeStage(target) == runtimeStage.SustainedServiceQuality {
+		return false
+	}
 	if readiness.StageGate.Status != "ready" {
 		return false
 	}

plan.md

@@ -30,6 +30,8 @@ Sustained Service Quality
 
 ## Target Stage
 
+Sustained Service Quality
+
 
 
 ## Build Style
@@ -69,4 +71,58 @@ Service Quality specifically requires repeatable validation, clear setup/update/
 
 ## Current Focus
 
-Before executing the next six product steps, add an auditable decision hierarchy that helps the AI choose work without exposing hidden chain-of-thought: safety boundary, product intent, evidence gap, smallest step, validation proof, learning/promotion signal. Then proceed step by step through autonomous packet format, safety policy, validator/harness expansion, research evidence, loop guard, and product satisfaction.
+Operate Hyper Run as an autonomous service-quality loop: the user should normally run only `hyper run`, while the AI reads the runtime packet, performs the smallest coherent step, validates it, writes evidence and next notes, runs the finish gate internally, and continues only when the next packet is safe, concrete, and evidence-producing.
+
+## Autonomous Service Quality Loop
+
+The loop exists to keep project direction intact while minimizing human attention. It should prefer project quality over activity volume.
+
+1. Human entrypoint
+   - The normal user action is `hyper run` or the equivalent Codex `$hyper-run` route.
+   - The user is not expected to run `hyper complete` in the ordinary flow.
+   - The user is asked only for approval-required actions, missing credentials/environments, ambiguous product ownership, or a deliberate scope change.
+
+2. Agent responsibility
+   - Read `plan.md`, the generated runtime packet, recent evidence, active capabilities, and `.hyper/next-packet.md`.
+   - Classify safety before action.
+   - Choose one smallest coherent episode.
+   - Run active validators or record a concrete reason they cannot run.
+   - Write evidence, next notes, durable Learn signals, and self review.
+   - Run the finish gate internally before starting another packet.
+
+3. Continue automatically when all are true
+   - `.hyper/next-packet.md` says `Action: run`.
+   - The next command is concrete and scoped to one episode.
+   - No destructive, credential-sensitive, publication, deployment, external-cost, production-data, or environment-changing action is required.
+   - The previous packet passed the finish gate.
+   - The next packet can produce code, validation evidence, readiness evidence, an active capability signal, a clearer blocker, or a changed next step.
+
+4. Stop when any are true
+   - Approval is needed for install/update, tag, push, release, deployment, branch deletion, credentials, external spend, production data, or similar high-risk action.
+   - A required environment is missing, such as Windows for Windows installer smoke or `cosign` for sigstore verification.
+   - Validation fails twice for the same reason.
+   - The next recommendation repeats without new evidence or a changed boundary.
+   - Product scope, target user, or current stage is unclear.
+   - `.hyper/next-packet.md` says `Action: stop`, or `Action: advance` without authorized stage advancement.
+
+5. Service-quality evidence
+   - Functional proof: active Go validators, targeted tests, command smoke, or artifact proof.
+   - Operational proof: install/update/release/checksum/signature/rollback/setup evidence when those surfaces are touched.
+   - Core UX proof: `hyper run`, `status`, `doctor`, and generated packet guidance keep users on the intended flow.
+   - Security proof: secrets are not exposed; release artifacts have checksum proof and signature proof when tooling exists.
+   - Maintainability proof: stale branches, dirty state, repeated friction, and unclear handoffs are closed or routed to the next packet.
+   - Product satisfaction proof: the result remains useful, coherent, and aligned with delegated autonomy, not merely test-passing.
+
+6. Validator and harness promotion
+   - Active validators are required until evidence says otherwise: `GOCACHE=/private/tmp/hyper-go-cache go test ./...`, `go test ./...`, and `git diff --check`.
+   - Promotable validators such as `hyper status --short`, fresh `init/run/status/doctor`, and stale wording guards should become active only after the activation threshold or explicit maintainer acceptance.
+   - A release-verification helper should wait until Windows smoke and sigstore-tooling decisions add one more stable pressure cycle.
+   - Do not create a harness from a single packet or from planning alone.
+
+7. Near-term service-quality order
+   - First, publish the autonomous-loop runtime fix as the next patch release using current-environment validation and release checks.
+   - Defer Windows installer smoke until a Windows-capable environment is available.
+   - Next, run optional `cosign` verification if installation is approved.
+   - Then promote repeated first-run/status validators only if another independent packet confirms the pressure.
+   - After that, audit operations and recovery notes for setup, update, rollback, and failed-packet recovery.
+   - Only after repeated release verification pressure should a project-owned release verification helper be created.