cabloy 5.1.212 → 5.1.214

package/.cabloy-version

@@ -1 +1 @@
-5.1.212
+5.1.214

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## 5.1.214
+
+### Improvements
+
+- Enhance the AI specification.
+- Refactor database reset logic.
+- Improve `printTip` output.
+
+## 5.1.213
+
+### Bug Fixes
+
+- Fix details.
+
 ## 5.1.212
 
 ### Features

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.212",
+  "version": "5.1.214",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [

package/repo-agent-governance/managed-assets.json

@@ -179,7 +179,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
+      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -193,7 +193,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
+      "sha256": "cc739f11ae129235375a461b7376d639af967e1c659d4735a03b0973ff53dbdd",
       "source": "skills/cabloy-spec-execution/SKILL.md",
       "target": ".agents/skills/cabloy-spec-execution/SKILL.md"
     },
@@ -249,7 +249,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
+      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".agents/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -515,7 +515,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
+      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -529,7 +529,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
+      "sha256": "cc739f11ae129235375a461b7376d639af967e1c659d4735a03b0973ff53dbdd",
       "source": "skills/cabloy-spec-execution/SKILL.md",
       "target": ".claude/skills/cabloy-spec-execution/SKILL.md"
     },
@@ -585,7 +585,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
+      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".claude/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "2948516f964a13242178b4f5969756d469f60cc1766616a53e899c5551cf443d",
+      "sha256": "0b196a0d31058bb1d54efd10cdd7acbe51534d5738a908af57ef13d285afea8a",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -865,7 +865,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
+      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -879,7 +879,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
+      "sha256": "cc739f11ae129235375a461b7376d639af967e1c659d4735a03b0973ff53dbdd",
       "source": "skills/cabloy-spec-execution/SKILL.md",
       "target": ".cursor/skills/cabloy-spec-execution/SKILL.md"
     },
@@ -935,7 +935,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
+      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".cursor/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "f4f6c2584bd58846e315ecf2c0772a47735ef0d1f24a72213d2d6ea13673db71",
+      "sha256": "f4242299ae0b3a95427caaf9b137032767afa381d29135254195107348c4c42b",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "f4f6c2584bd58846e315ecf2c0772a47735ef0d1f24a72213d2d6ea13673db71",
+      "sha256": "f4242299ae0b3a95427caaf9b137032767afa381d29135254195107348c4c42b",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

package/repo-agent-governance/policies/repository.md

@@ -69,6 +69,8 @@ Before inventing a custom implementation path:
 - In SSR, keep server HTML and the client's hydration-time initial render equivalent. When server rendering intentionally omits private, cookie-unavailable, or browser-only state, keep the same neutral shell or placeholder through hydration and defer its query/load/render branch to an explicit post-hydration, admission, mounted, or interaction boundary.
 - Keep portable repo-wide AI rules short and durable in `repo-agent-governance/policies/`; put branching root workflows in `repo-agent-governance/skills/` and regenerate platform adapters instead of hand-editing them.
 - Treat hooks, permissions, local settings, credentials, MCP registration, command discovery, and automatic command execution as platform-specific integrations, not portable rule or skill capabilities.
+- Plan to resolve named blockers for a bounded increment, not every future detail. Define finite exit criteria, batch related decisions, and require new facts, decision value, or explicit blocker reduction for further planning; do not substitute repeated refinement for delivery.
+- Scope blockers to their actual dependency branches and surface meaningful, independently verifiable implementation candidates elsewhere without executing them unapproved. Once the selected increment is ready, request missing execution approval or proceed within existing unchanged approval; do not repeatedly reconfirm the same scope. Preserve security gates and separate runtime evidence/release requirements; neither a planning-round quota nor empty scaffolding justifies bypass or completion.
 - After implementation, do not launch broad reviews automatically; when review is needed, scope it to the current diff and report only high-confidence issues.
 - Do not modify shared environment identity or ports merely to bypass a busy resource. For intentional parallel worktree setup, follow `repo-docs/fullstack/parallel-worktree-environment.md`; otherwise wait for the shared resource or ask the user. Create or change worktree-local environment overrides only through the explicitly invoked `cabloy-worktree-environment` skill and its confirmation phase, and only in `vona/env/.env.local` and `zova/env/.env.local`; never modify flavor-, mode-, app-mode-, or runtime-specific `.env.*.local` files. The skill derives the standard `APP_NAME`, `SERVER_LISTEN_PORT`, `DEV_SERVER_PORT`, `DEV_SERVER_HMR_PORT`, and API-derived `API_BASE_URL` tuple only from Git worktree metadata and fixed port baselines; never read or expose `.env*` content while recommending values. Admin and Web are alternative commands using this shared tuple and must not run concurrently in one worktree; use another linked worktree for concurrent use. Detect the active edition before choosing scripts, and never run `npm run init` as an automatic follow-up.
 - In Cabloy Basic and Cabloy Start, root `npm run test` and `npm run test:e2e` allocate an isolated same-checkout test run: disposable run-specific database and Redis namespaces, runtime/public paths, and listener. Ordinary same-checkout dev-process presence alone is not a blocker; do not require dev shutdown, another worktree, or environment changes solely to run these tests. Judge conflicts by actual overlap with effective test resources or shared preparation writes, not process names. Builds and dependency installation/generation remain shared prerequisites; coordinate overlapping writes, and check custom external resources separately. This guarantee does not cover raw test commands or authorize manual resets, process killing, or shared configuration changes. See `repo-docs/reference/repo-scripts.md`.

package/repo-agent-governance/skills/cabloy-spec-execution/SKILL.md

@@ -90,9 +90,13 @@ Classify targets as observed existing, proposed new, or explicitly approved new.
 
 Require explicit dossier approval before source changes, meaningful verification, or evidence/status updates. Generation approval, design/ADR acceptance, and this execution approval are separate; silence is not approval.
 
+Reuse an already explicitly approved dossier when the target, scope, authority, dependencies, safety conditions and permitted operations remain valid. Check current revision/worktree attribution and evidence applicability; a revision change alone calls for an impact check, not automatic reapproval. Do not request the same approval again merely because a skill handoff, session continuation or implementation substep occurred. Refresh affected parts and seek renewed approval only when a material change, newly observed risk or the approval's own conditions require it. Existing approval never expands to another task or an unapproved external/destructive operation.
+
 ## Step 5: Apply readiness gates
 
-Stop and route back to the relevant planning authority if any of the following applies:
+Apply these gates to the selected increment and its actual dependencies, not every unresolved detail in the suite. Separate start-readiness from the runtime evidence this increment will produce and from later release gates; predecessor proof remains mandatory. If blocked, name the exact condition, affected branch and closure criterion in the existing records. Recommend a meaningful dependency-ready alternative for approval when one exists, without silently changing the target or its status. A smaller subincrement of a blocked WBS requires a justified independent boundary and explicit approval; it cannot bypass a controlling safety gate or claim parent completion.
+
+Stop and route only the affected authority questions back to planning if any of the following applies:
 
 - the suite identity, ownership, or target boundary is unresolved;
 - PRD/SRS/ADR/WBS/test-plan records contradict one another;
@@ -106,6 +110,8 @@ Stop and route back to the relevant planning authority if any of the following a
 
 A task may be marked `in-progress` only when approved execution actually starts. Do not edit progress merely to reserve a task.
 
+Once the selected increment is ready and explicitly approved, execute its coherent implementation and verification steps without adding another preparation/review cycle by default. Any proposed planning return must identify the new fact, material authority question or concrete blocker it resolves and a finite exit condition; restating accepted direction is not sufficient. Batch related unresolved decisions rather than serializing each into another micro-plan. Preserve all mandatory reviews and safety/authorization gates; no round quota forces implementation.
+
 ## Step 6: Route the approved increment
 
 After confirmation, route the smallest coherent implementation unit:

package/repo-agent-governance/skills/cabloy-spec-execution/references/execution-protocol.md

@@ -71,7 +71,9 @@ Before implementation, verify:
 - tenant, identity, authorization, ownership, privacy, lifecycle, transaction, concurrency, idempotency, audit, and recovery constraints are defined for the task’s risk;
 - the requested change does not broaden scope or create a competing persistence, identity, or API authority.
 
-When authority records conflict, stop. Update the authoritative PRD, SRS, or ADR through `cabloy-spec-generation`, then propagate the change through WBS, ATP, evidence assumptions, and progress. Do not reconcile a conflict by silently editing a downstream status or implementation plan.
+Apply readiness to the selected increment and its real dependency graph. Record each blocker with its affected branch, decision owner and finite closure condition in existing records; keep future refinements and release-only questions separate. Do not require the new implementation's runtime ATP evidence before implementation starts, but retain required predecessor evidence and any specifically mandated pre-implementation qualification. When blocked, surface one meaningful, independently verifiable alternative if available, without executing it unapproved or changing formal dependencies/status to bypass the blocker. A foundation-only subincrement needs concrete integration value, checks and explicit scope approval; it does not complete the parent WBS.
+
+When authority records conflict, stop the affected work. Update the authoritative PRD, SRS, or ADR through `cabloy-spec-generation`, then propagate the change through WBS, ATP, evidence assumptions, and progress. Do not reconcile a conflict by silently editing a downstream status or implementation plan. A return to planning must name the new fact, material authority question or blocker to resolve and its exit condition; do not restart a preparation/review cycle merely to restate accepted direction. Batch related decisions and report stalled convergence if further refinement has no justified new value.
 
 ## 4. Special gates
 
@@ -123,7 +125,7 @@ Excluded operations: <init/reset/deploy/provider/etc.>
 Next action: <one action after confirmation>
 ```
 
-Require explicit confirmation. If the user changes scope, rebuild the dossier and re-check dependencies and authority. A prior confirmation does not authorize a new task, phase, provider operation, or destructive command.
+Require explicit confirmation unless this same bounded dossier already has valid explicit approval. Reuse unchanged approval across skill handoffs, session continuations and implementation substeps after checking current revision/worktree attribution and evidence applicability. Revision change alone requires an impact check, not automatic reapproval. Refresh affected dossier parts and obtain renewed approval for material scope/authority/dependency/safety changes, newly observed risks or conditions specified by the approval. A prior confirmation does not authorize a new task, phase, provider operation, or destructive command. Once ready and approved, proceed with the coherent implementation/verification sequence rather than requesting the same permission or another planning round by default.
 
 ## 6. Specialist routing
 

package/repo-agent-governance/skills/cabloy-spec-generation/SKILL.md

@@ -69,6 +69,16 @@ Ask only for missing inputs in a compact clarification pass:
 
 Label recommendations as proposals. A request for comprehensiveness is not permission to invent security or business decisions.
 
+### Planning convergence
+
+For the next bounded increment, keep a finite blocker/exit checklist in the existing owning records, not a new planning hierarchy. Name each material unresolved decision, why it blocks this increment, its decision owner and closure condition; separate deferrable details and future increments. Batch related decisions into a compact review rather than mechanically splitting preparation, review and reconfirmation into separate rounds.
+
+Before proposing more planning, identify the blocker or material uncertainty it addresses, the new fact or decision value expected, and the exit condition or resulting implementation handoff. If another pass merely restates accepted direction or leaves the same blockers without a justified new approach, report the stalled convergence and recommend a concrete decision, bounded feasibility check or scope disposition instead of another micro-plan. Do not impose a fixed round limit or weaken security requirements to force code.
+
+Apply blockers only along actual dependencies, not to the whole suite by default. Surface one meaningful, independently verifiable implementation candidate on an unaffected branch when available; do not invent one or use empty scaffolding/document counts as progress. A foundation-only increment must have explicit integration value and its own checks, and must not be reported as completion of its parent feature. If none is ready, state the exact reason.
+
+Stop refining when the selected increment's material contracts, dependencies, scope, safety constraints and verification plan are sufficient. Request only missing execution approval, or hand off within existing explicit approval whose scope and conditions remain valid. Reopen settled decisions only for a material change or newly observed risk. Generation/design approval alone still does not authorize implementation; runtime ATP proof and release approval remain later gates, not proof that must already exist for the new implementation to start.
+
 ## 6. Confirm generation scope
 
 Before writing, present the edition/root, mode, identity/path, intended ownership, outcomes/scope, site strategy/target tuple classification, affected records, justified omissions/extensions, unresolved gates, and initial status/evidence policy. Include planned chart eligibility and README language.

package/repo-docs/ai/ai-spec-driven-development.md

@@ -73,6 +73,18 @@ Before source work begins, an **execution dossier** makes the unit explicit: tar
 
 This structure lets a team pause, review, or transfer work without treating an unfinished implementation as verified. See [Execute an Approved Cabloy Specification Increment](/ai/playbook-spec-execution) for the readiness gates, routing rules, evidence protocol, and handoff format.
 
+## Converge planning into implementation
+
+Planning should resolve the material blockers of the next bounded increment, not specify every future detail before any code is written. Keep a finite blocker/exit checklist in the existing owning records: the unresolved decision, why it blocks this increment, its decision owner, and the condition that closes it. Separate deferrable details and later increments; batch related decisions instead of turning each clarification into another preparation and review cycle.
+
+Before adding a planning pass, explain which blocker or material uncertainty it addresses, what new fact or decision value it should provide, and how it ends. If the next pass only restates an accepted direction without a justified new approach to the remaining blockers, report stalled convergence and recommend a concrete decision, bounded feasibility check, or scope disposition. A larger document or another review is not delivery progress by itself.
+
+Blockers follow actual dependencies, not the whole suite by default. A blocked identity integration does not necessarily block an independent capability whose own contracts, dependencies, safety boundary, and verification plan are ready. Conversely, a frontend change that depends on an unresolved response contract cannot bypass that dependency by calling itself an independent increment. Surface a meaningful, independently verifiable candidate for approval when available; if none exists, state why. Foundation-only work is useful only when it has explicit integration value and checks, not merely an empty scaffold presented as feature completion.
+
+Planning is sufficient for an increment when its material contracts, dependencies, scope, safety constraints, and verification plan are settled. At that point, request any missing execution approval or proceed within valid existing approval. Reuse an unchanged approved dossier after checking current revision, worktree attribution, and evidence applicability; a skill handoff, resumed session, or ordinary implementation substep is not a reason to request the same permission again. Material changes, newly observed risks, and the approval's own conditions can require renewed approval; prior approval never covers unrelated tasks or unapproved external/destructive operations.
+
+This is not a fixed limit on planning rounds or a relaxation of security requirements. Preserve mandatory reviews, predecessor proof, and any specifically required pre-implementation qualification. The new implementation's runtime ATP proof normally follows implementation; it must not become an impossible prerequisite to writing that implementation. Evidence and release gates still control later verification and release claims. A genuine new risk can reopen planning, but the return should name the affected blocker and its exit condition rather than restart open-ended refinement.
+
 ## Contract Loop is complementary
 
 [Contract Loop](/fullstack/contract-loop-playbook) is Cabloy's bidirectional Vona↔Zova synchronization model. It determines where fullstack contract truth lives, which generated handoff must be refreshed, and how to recover from forward-chain, reverse-chain, consumer, or local-dependency drift.

package/repo-docs/backend/migration-and-changes.md

@@ -173,6 +173,8 @@ This is valuable because shared baseline data becomes part of the structured ver
 
 Vona invokes `seed()` while the application starts in test mode (`npm run test` or managed E2E), and during an explicit `npm run db:reset` in dev mode. In **Cabloy Basic and Cabloy Start**, ordinary `npm run dev` and `npm run dev:one` only reuse existing managed disposable databases and never seed; a missing required database makes startup fail with an instruction to run `npm run db:reset`. Framework upgrades do not reset existing development data or repeat its seeds. Use `seed()` for durable baseline fixtures shared by tests or for freshly prepared local development data. Seeding follows instance initialization on a newly created or recreated disposable database; `seed()` is not a repeatable, same-database data-import mechanism. See [Managed development database preparation](#managed-development-database-preparation) for the explicit reset lifecycle.
 
+In **Cabloy Basic and Cabloy Start**, automatic `seed()` execution is limited to the default instance (`''`). These records are convenience fixtures for test/dev use, not required business initialization data. Reset still migrates and initializes configured isolated targets such as `isolateTest`, but does not seed them: they can exercise multi-instance behavior without shared test fixtures. Use `init()` for initialization required by each instance.
+
 Treat shared `seed()` records as read-only in ordinary tests. A scenario that needs different state must create independent, test-owned data and clean it up in `finally`; it must not mutate or delete the shared baseline. `seed()` remains distinct from `init()`: use `init()` for instance-aware initialization data and reserve `seed()` for baseline data in test runs or explicit development resets.
 
 ## Version changes across the generated backend thread
@@ -217,7 +219,9 @@ When `database.testDatabase: true` enables framework-managed disposable dev data
 1. **Check every required target:** both shared and statically configured isolate database targets must exist. If any required target is missing, startup fails promptly with an instruction to run `npm run db:reset`; it does not create the target, perform creation-time Redis cleanup, or seed as a fallback.
 2. **Reuse existing databases:** keep their data without database creation, creation-time Redis cleanup, or module seeding. Ordinary startup is not a fixture refresh, an implicit reset, or recovery for a partial reset. Non-disposable databases are outside this managed reset path.
 
-An explicit `npm run db:reset` owns preparation in a single process. It requires `database.testDatabase: true` and a connection outside the disposable database. It clears validated application-owned Redis state with `clearAllData()`, drops and recreates the managed disposable dev databases, runs migrations and instance initialization, then invokes the owning modules' `seed()` hooks.
+An explicit `npm run db:reset` owns preparation in a single process. It requires `database.testDatabase: true` and a connection outside the disposable database. It clears validated application-owned Redis state with `clearAllData()`, drops and recreates the managed disposable dev databases, and runs migrations. It then completes each instance's non-after startups and initialization in sequence. Only the default instance runs the owning modules' `seed()` hooks, after its initialization and before consuming its creation bookkeeping and setting its readiness flag; isolated instances initialize and become ready without seeding.
+
+Reset skips all instance and application startups with `after: true`: schedule loading, runtime JSON generation, development tips, queue-worker preloading, and HTTP listening are runtime-server work, not reset prerequisites. Put required data preparation in migrations, `init()`, `seed()`, or non-after startups. Normal dev startup still runs after-startups; independent framework lifecycle hooks and reset's application teardown remain intact. See [Backend Startup Guide](/backend/startup-guide#app-startup-and-instance-startup-in-practice) for the phase boundary.
 
 **Stop the development server and any other processes using the same database and Redis namespace first.** There is no file-based preparation lock; concurrent dev/dev and dev/reset against the same database and Redis namespace are unsupported. The reset command disables its own listener, but that does not protect a concurrently running server or queue worker. Never reset development data you need to keep.
 

package/repo-docs/backend/startup-guide.md

@@ -232,7 +232,7 @@ In the current runtime behavior:
 - in `test` and `dev`, the default instance is started eagerly
 - in production-style flows, configured static instances are started from `config.instance.instances`
 
-A practical timeline is:
+For ordinary startup without newly created development databases, a practical timeline is:
 
 1. run non-instance startups with `after !== true` during app start
 2. run non-instance startups with `after === true` during app ready
@@ -241,6 +241,21 @@ A practical timeline is:
 5. mark `appReadyInstances[instanceName] = true`
 6. run instance startups with `after === true`
 
+Explicit development preparation through `npm run db:reset` is a data-preparation flow in **Cabloy Basic and Cabloy Start**. It retains non-instance startups with `after !== true`, including database migration and database-name preparation, then completes the default instance and each newly created isolated instance:
+
+1. run the instance's startups with `after !== true`, including instance initialization
+2. for the newly created default instance (`''`) only, run module `seed()` hooks for test/dev convenience fixtures
+3. consume the instance's creation bookkeeping and mark it ready
+4. repeat for the next instance, without seeding isolated targets such as `isolateTest`
+
+Reset skips all instance and non-instance startups with `after === true` before dispatch. This excludes schedule loading, runtime JSON generation, development tips, queue-worker preloading, and HTTP listening, including their startup execution logs. Normal dev startup retains these runtime tasks and generates runtime JSON when the server starts. Skipping queue-worker preloading does not disable queues: an explicit queue push can still create a worker lazily, and fire-and-forget jobs are not automatically drained by reset.
+
+Reset-required preparation must belong to migrations, `init()`, `seed()`, or a non-after startup; do not depend on an after-startup for required data. This phase filter does not bypass independent framework monkey hooks such as `appStarted`, or application teardown.
+
+Each instance completes preparation in one queued startup task. Ordinary queued readiness requests skip reinitialization once the instance is ready, even though its after-startups were skipped. A failed default seed leaves its creation marker unconsumed and its readiness unset. There is no all-instances atomic readiness guarantee: if a later instance fails, an earlier instance may already be ready; the failure still stops preparation. Outside reset, explicitly forced startup requests retain their force behavior through instance after-startups.
+
+Test-mode default seeding retains its existing lifecycle after default instance startup. Ordinary dev startup reuses existing databases without seeding. See [Managed development database preparation](/backend/migration-and-changes#managed-development-database-preparation) for reset safety and seed ownership.
+
 This is why startup should be read together with the instance and datasource story rather than as a purely global boot topic.
 
 ## Teardown-oriented monkey examples

package/repo-docs/frontend/permission-formscene-action-visibility-guide.md

@@ -214,11 +214,11 @@ The current source confirms:
 
 That means the details action family is scene-aware in a different way from `tableActionBulk`.
 
-A practical current example from backend DTO metadata is:
+A practical details example from backend DTO metadata is:
 
 ```tsx
 ZovaRender.detailsActionBulk('basic-details:actionCreate', {
-  permission: { formScene: ['create', 'edit'] },
+  permission: { mode: 'formScene', formScene: ['create', 'edit'] },
 });
 ```
 
@@ -226,15 +226,17 @@ and:
 
 ```tsx
 ZovaRender.detailsActionRow('basic-details:actionDelete', {
-  permission: { formScene: ['create', 'edit'] },
+  permission: { mode: 'formScene', formScene: ['create', 'edit'] },
 });
 ```
 
+For default detail CRUD actions, `permission.mode: 'formScene'` makes the intent explicit: the enclosing form scene controls visibility and no independent action permission check is performed. Custom detail actions should use `permission.mode: 'action'`; an explicit `actionInherit` also takes the action-checking path. If `mode` is omitted, the runtime uses the conservative action-checking path rather than inferring behavior from the action name.
+
 So the correct distinction is:
 
 - `tableActionBulk` does not currently support `formScene`
-- `detailsActionBulk` does support `formScene`
-- `detailsActionRow` also supports `formScene`
+- `detailsActionBulk` supports `formScene` and the detail-specific `mode`
+- `detailsActionRow` supports `formScene` and the detail-specific `mode`
 
 ## 7. Why bulk actions are different today
 

package/repo-docs/reference/repo-scripts.md

@@ -166,7 +166,9 @@ With `database.testDatabase: true`, `npm run dev` and `npm run dev:one` only reu
 - **All required databases exist:** startup reuses them without database creation, creation-time Redis cleanup, or module seeding. Ordinary startup is not a reset or a repeatable fixture-import path.
 - **Any required database is missing:** startup fails promptly with an instruction to run `npm run db:reset`. This check covers both shared and statically configured isolate database targets; the presence of the shared database alone is not sufficient. Startup does not create the missing target or clear Redis or seed as a fallback.
 
-`npm run db:reset` is the explicit, destructive preparation command. It requires `database.testDatabase: true` and a connection outside the disposable database. In a single process, it clears validated application-owned Redis state with `clearAllData()`, drops and recreates the managed disposable dev databases, then runs migrations, instance initialization, and module `seed()` hooks.
+`npm run db:reset` is the explicit, destructive preparation command. It requires `database.testDatabase: true` and a connection outside the disposable database. In a single process, it clears validated application-owned Redis state with `clearAllData()`, drops and recreates the managed disposable dev databases, then runs migrations and instance initialization. In both editions, only the default instance (`''`) runs module `seed()` hooks, supplying test/dev convenience fixtures before consuming its creation bookkeeping and marking it ready. Configured isolated targets such as `isolateTest` initialize and become ready without fixture seeding. Each instance completes preparation in sequence.
+
+Reset retains non-after startups and skips all instance and application startups with `after: true`, including schedules, runtime JSON generation, development tips, queue-worker preloading, and HTTP listening. Required data preparation must not depend on after-startups. Normal dev startup retains these runtime tasks; independent framework lifecycle hooks and application teardown still run during reset. See [Backend Startup Guide](/backend/startup-guide#app-startup-and-instance-startup-in-practice).
 
 **Stop the development server and any other processes using the same database and Redis namespace before running reset.** There is no file-based preparation lock: concurrent dev/dev and dev/reset processes against the same database and Redis namespace are unsupported. Disabling the reset command's own listener does not make reset safe alongside a live server or queue worker. Do not reset data you need to retain.
 

package/vona/packages-cli/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-cli",
-  "version": "1.1.162",
+  "version": "1.1.163",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona cli",
   "keywords": [

package/vona/packages-cli/cli-set-api/cli/templates/tools/masterDetail/boilerplate/dto/<%=argv.detailDtoResItemName%>.tsx_

@@ -19,7 +19,7 @@ export interface IDtoOptions<%=cli.helper.firstCharToUpperCase(argv.detailDtoRes
           actions: [
             ZovaRender.detailsActionBulk('<%=argv.detailsModuleName%>:actionCreate', {
               dialogOptions: { title: $locale('Add<%=argv.detailDialogTitleCapitalize%>') },
-              permission: { formScene: ['create', 'edit'] },
+              permission: { mode: 'formScene', formScene: ['create', 'edit'] },
             }),
           ],
         }),
@@ -48,10 +48,10 @@ export class Dto<%=cli.helper.firstCharToUpperCase(argv.detailDtoResItemName)%>
       actions: [
         ZovaRender.detailsActionRow('<%=argv.detailsModuleName%>:actionUpdate', {
           dialogOptions: { title: $locale('Edit<%=argv.detailDialogTitleCapitalize%>') },
-          permission: { formScene: ['create', 'edit'] },
+          permission: { mode: 'formScene', formScene: ['create', 'edit'] },
         }),
         ZovaRender.detailsActionRow('<%=argv.detailsModuleName%>:actionDelete', {
-          permission: { formScene: ['create', 'edit'] },
+          permission: { mode: 'formScene', formScene: ['create', 'edit'] },
         }),
       ],
     }),

package/vona/packages-cli/cli-set-api/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-cli-set-api",
-  "version": "1.1.160",
+  "version": "1.1.161",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona cli-set-api",
   "keywords": [

package/vona/packages-vona/vona/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona",
-  "version": "5.1.108",
+  "version": "5.1.109",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "Vona is an intuitive, elegant and powerful Node.js framework for rapidly developing enterprise applications of any size",
   "keywords": [