@codetreker/daynight 0.20.2 → 0.21.2

package/dist/commands/skill/skills/using-daynight/references/create-task.md

@@ -1,7 +1,8 @@
 # Create a task
 
 Use this mode to prepare and register work that needs persistent tracking. Read
-[the handbook](handbook.md) before discovery, queries, or writes. Return after
+[the handbook](handbook.md) before discovery, queries, or writes and
+[the task content standard](task-content.md) for content preparation. Return after
 registration; registration alone does not authorize execution or
 autopilot. An explicit request to start a Goal discussion routes the registered
 current stage to run-task under the Goal protocol.
@@ -52,50 +53,34 @@ applicable mock UI before registration, following the artifact rules below.
 
 Look for existing work with the same problem and scope, including completed
 tasks; the default list contains only unfinished work. Inspect full descriptions,
-actual dependencies, primary Markdown, and acceptance criteria. For a Goal,
+actual dependencies, content sources, and acceptance criteria. For a Goal,
 inspect the existing chain and its owning inputs. Titles alone do not establish
 identity. Reuse suitable work and preserve valid requirements; interrupted
 registration does not justify a duplicate task or chain.
 
 ## Write task-specific content
 
-Use the target repository's document and workspace rules.
-
-| Content | Owner |
-|---|---|
-| Concrete problem, current actions and scope, deliverables, constraints, completion summary, and real input references | Task `description` |
-| Detailed solution, full acceptance criteria, verification methods, and completion evidence | This task's primary Markdown attachment |
-| Applicable visual and interaction design | Owning task's interactive mock UI and resources, referenced by consumers |
-| Prerequisite tasks and edge classification | Complete `dependsOn` plus its `externalDependsOn` subset |
-| Delivery PR URLs and titles | `properties.pullRequests` |
-
-Give each task an outcome-focused title and a self-contained Markdown
-description: a reader must understand what this specific task will do, deliver,
-and verify without opening attachments. Summarize the approach and observable
-completion conditions, then reference the real detailed sources. A generic
-problem sentence and a link list are insufficient. Keep the summary consistent
-with its primary Markdown without maintaining a second complete plan in the
-description.
-
-The primary Markdown must contain **Solution** and **Acceptance criteria**
-sections; equivalent headings in the task's language are valid. Define the
-current task's approach, scope, behavioral constraints, observable completion
-conditions, and how to verify them. Stage briefs describe the work that will
-produce that stage's results. They do not claim unfinished outputs already exist.
-Link supporting resources from the primary document.
-
-Attach only this task's detailed plan, needed resources, and outputs. Shared
-Goal requirements stay with the Goal description task; architecture and
-breakdown stay with the design task. Consumers identify the source task ID and
-attachment path and confirm the contents using the installed CLI's attachment
-read command. For repository inputs, use verified immutable references. Do not
-assume a `task://` scheme, cross-task relative links, or a fixed service host.
-For every Goal delivery task, list the architecture task ID and all required
-architecture document references directly in its description, including indirect
-successors. Use the Goal protocol's full attachment paths or immutable repository
-references; keep these input references separate from execution dependencies.
-Do not upload the same whole packet to every task. Create a separate snapshot
-only when the task needs an independent copy, recording its purpose, original
+Use the target repository's document and workspace rules and the shared six-item
+content standard. Give each task an outcome-focused title and a Markdown
+description that identifies its concrete work, responsibility, and actual content
+sources. The description and readable references together provide the objective,
+scope, solution, exchange contracts, acceptance, and sources. Complete inline
+content needs no primary attachment; reference-owned and mixed content are also
+valid without repeating complete documents. State where this task's confirmations,
+acceptance conclusions, and delivery evidence will live in its description or
+attachments. Stage briefs describe work that produces the stage's outputs; do
+not claim unfinished outputs already exist.
+
+Attach only resources this task needs or owns. Keep shared Goal requirements
+with the requirements task and architecture and breakdown with the solution
+task. Reference the owning task ID and its description with applicable sections
+for inline content, full paths for actual attachments, or verified immutable
+repository sources. Read source descriptions through `task show --json` and
+attachment bytes through the attachment commands. For every Goal delivery task,
+list the architecture task ID and all required architecture source locations
+directly in its description, including indirect successors, as
+[the Goal protocol](goal.md) requires. Do not copy the whole shared packet
+into every task. An independently needed snapshot records its purpose, original
 source, and source revision or content identity.
 
 A frontend delivery task requires an interactive mock UI that runs with frontend code
@@ -115,8 +100,8 @@ ownership before registering the relationship. A top-level task has no ordinary
 prerequisites; it may still have real external prerequisites that block execution.
 Do not add a Dependencies section or duplicate the relationship lists in task
 prose. Repository specifications and design documents retain their full contracts;
-the task's own primary attachment still provides its specific solution and
-verifiable acceptance criteria.
+the current task identifies its specific solution and verifiable acceptance
+criteria directly or through their actual owners.
 
 ## Author Markdown
 
@@ -130,8 +115,9 @@ A relative link or image in a description starts at this task's attachment root.
 A link inside a Markdown attachment starts at that file's directory. Keep paths
 inside the task root and preserve the actual case and resource identity. Confirm
 an upload and read back its contents before adding its link. Reference shared
-inputs by their verified source task ID and attachment path or immutable
-repository URL; a relative link cannot identify another task's attachment.
+inputs by their verified owning task ID and description/sections or actual
+attachment path, or by an immutable repository URL. A relative link cannot
+identify another task's content.
 
 For example, the following brief applies to a task whose confirmed, readable
 attachments include its own `plan.md` and the complete `mockui/index.html`
@@ -156,14 +142,17 @@ confirming it.
 - [交互原型](mockui/index.html)
 ```
 
-This remains a concise assignment. Its own primary Markdown still contains the
-specific **Solution** and **Acceptance criteria**, verification methods, and
-evidence. The prototype remains with its actual owner when shared across a Goal.
+This example uses an attachment for the detailed content; the same six-item
+standard also permits complete inline or mixed organization. Its actual `plan.md`
+provides the requirements, solution, applicable exchange contracts, acceptance,
+and task-owned evidence location. The prototype stays with its actual owner when
+shared across a Goal.
 
 ## Register and verify
 
 New tasks have `allowAgents=false`; creation cannot enable the permission.
-Automatic workers and agent workflows must not turn it on themselves. Execution
+Creation and breakdown do not enable it. A separate, explicitly requested
+[handoff](handoff.md) reviews each task before enabling permission. Execution
 authorization and automatic-discovery permission remain separate decisions.
 
 Tasks without `--required-platform` are unrestricted. Set windows, linux or macos
@@ -172,16 +161,17 @@ do not start tasks or enable automatic execution; they survive all status change
 
 Reuse the established project and suitable tasks. Create new tasks in `todo`,
 retaining each confirmed ID. Set concrete descriptions and actual ordinary and
-external prerequisites using the handbook's full CLI replacement rule. Upload each task's own primary Markdown and required
-resources; add actual attachment references to the complete description using
-the observed task version. Reference already readable shared inputs at their
-source. Do not present planned uploads as existing attachments.
+external prerequisites using the handbook's full CLI replacement rule. Upload
+required task-owned resources when the content uses attachments; add actual
+references to the complete description using the observed task version. Reference
+already readable shared inputs at their source. Do not present planned uploads as existing attachments.
 
 Read back each complete task, its attachment inventory and required contents,
 and its referenced shared inputs. Verify self-contained Markdown descriptions,
-valid links and images, the two required primary-document sections, real source
-identities, complete prerequisites and their intended external subset, and applicable mock UI resources and
-interaction. For a Goal, verify only the current discussion stage and its brief;
+valid links and images, all six content requirements, the explicit task-owned
+evidence location, real source identities, complete prerequisites and their
+intended external subset, and applicable mock UI resources and interaction. For a
+Goal, verify only the current discussion stage and its brief;
 verify later stages and delivery tasks when their confirmation gate permits
 registration. When registering delivery work, check every task's description,
 including indirect successors, for its architecture task ID and required document
@@ -197,8 +187,8 @@ scope; ready successors in an authorized fixed queue need no per-task authorizat
 If creation succeeds but a later operation fails, retain the confirmed IDs and
 resume missing operations there. Tasks remain `todo`. Reconcile uncertain results through the handbook before another
 mutation. Report incomplete registration with the exact missing operation or
-artifact and next step. Do not move detailed plans into descriptions to bypass
-an attachment failure. Return after verified registration without selecting or
-executing a task for registration-only requests. If the user explicitly requested
+artifact and next step. An unreadable required source is still a failure; do
+not silently replace it with invented or weaker content. Return after verified
+registration without selecting or executing a task for registration-only requests. If the user explicitly requested
 the current Goal discussion to start, pass its confirmed ID to run-task under
 the Goal protocol.

package/dist/commands/skill/skills/using-daynight/references/goal.md

@@ -2,7 +2,8 @@
 
 Read this reference when starting or registering a Goal, discussing one of its
 stages, or advancing its authorized scope. Use [create-task](create-task.md) for
-content and registration, [run-task](run-task.md) for task execution, and
+registration, [the task content standard](task-content.md) for the shared six
+content requirements, [run-task](run-task.md) for task execution, and
 [the handbook](handbook.md) for CLI semantics. A Goal uses existing tasks,
 attachments, complete `dependsOn` relationships, their `externalDependsOn`
 classification, and PR properties. It adds no resource, command, or status.
@@ -35,8 +36,9 @@ Create or reuse only the requirements discussion task, titled `[Goal]<outcome>`.
 The marker is followed directly by the outcome. Do not create an architecture
 placeholder or delivery tasks at this point. Give the task a self-contained Markdown description
 for the known problem, intended outcome, scope, constraints, open
-questions, and observable completion conditions. Its primary Markdown's Solution
-and Acceptance criteria describe this discussion and its user-confirmation gate;
+questions, and observable completion conditions. The description and actual
+references provide this discussion's solution, acceptance criteria, confirmation
+gate, and task-owned evidence location under the shared content standard;
 finished requirements and prototypes are outputs, not prerequisites to starting.
 
 Each task starts in `todo`. For an explicit discussion-start request, read its
@@ -49,8 +51,8 @@ task is resumed after checking its actual work and context.
 Discuss requirements with the user: the whole problem, desired behavior, scope,
 constraints, exclusions, and whole-Goal acceptance. Keep current material and open
 questions in this task's description or attachments. The description remains a
-self-contained brief; its primary Markdown owns detailed requirements, validation,
-and evidence. Before requesting user review, save the complete current material,
+task-specific brief and source entrypoint; detailed requirements have one owner,
+and confirmation, validation, and evidence stay at an identified task-owned location. Before requesting user review, save the complete current material,
 read it back, and provide the task and resource reference.
 
 For a UI Goal, produce a final-style interactive frontend-only prototype with
@@ -111,9 +113,9 @@ either discussion does not establish whole-Goal completion.
 ## Register the confirmed delivery breakdown
 
 Only after user solution confirmation, create or reuse the concrete delivery tasks
-needed for the agreed outcome. Each needs its own problem, objective, scope,
-deliverables, constraints, solution, observable acceptance, verification methods,
-and real input references. Include independently scoped acceptance work when it
+needed for the agreed outcome. Each description and its actual references must
+satisfy the six-item content standard, including task-specific responsibility,
+input/output contracts, observable acceptance, verification, and evidence ownership. Include independently scoped acceptance work when it
 has its own outcome. A [final-acceptance](../SKILL.md#final-acceptance) brief
 identifies the original whole-Goal requirements and confirmed changes, and assesses
 the combined delivery under the shared rule. Do not turn agent-generated execution
@@ -124,7 +126,9 @@ Create new delivery tasks in `todo`. Solution confirmation authorizes the
 confirmed breakdown's registration, not implementation, autopilot,
 automatic-execution permission, publishing, deployment, or merge. Apply any
 separate explicit authorization only within its stated scope. New tasks have
-`allowAgents=false`; automated workflows must not enable it themselves.
+`allowAgents=false`; registration does not enable it. Only a separately explicit
+[handoff](handoff.md) may review and enable permission; it does not supply delivery
+execution authorization or advance the discussion gate.
 
 Use ordinary dependencies for real within-Goal prerequisites. Every delivery root
 without another ordinary implementation prerequisite depends directly on the
@@ -134,16 +138,19 @@ external prerequisites remain real blockers and do not replace that ordinary
 design gate. Preserve the complete relationship sets under the handbook's CLI
 replacement semantics. Do not create dependencies merely to group cards.
 
-Upload each task's own primary Markdown and needed resources. Keep shared
-requirements with the requirements task and the solution and breakdown with the
-solution task. Consumers reference the verified source task ID and attachment
-path, or an immutable repository source. Every delivery task's description must
-directly list the architecture task ID and every architecture document required
-for that task, using its full attachment path under the source task. For a
-repository document, retain the architecture task ID and use a verified immutable
-repository reference. Include applicable sections when they clarify what to read.
-This applies to indirect successors as well as delivery roots; a reference only
-in another task or the delivery task's own primary Markdown is insufficient.
+Upload needed task-owned resources when their content uses attachments. Keep
+shared requirements with the requirements task and the solution and breakdown with the
+solution task. Consumers reference the owning task ID and the source description
+with applicable sections for inline content, full paths for actual attachments,
+or immutable repository sources. Use `task show --json` for source descriptions
+and the attachment commands for actual attachment contents. Every delivery
+task's description must directly list the architecture task ID and all required
+architecture source locations: description and applicable sections for inline
+design, full paths under the source task for each actual required attachment
+document, and verified immutable repository references for repository documents.
+Do not fabricate an attachment path or copy or relocate inline architecture to
+fit this index. This applies to indirect successors as well as delivery roots;
+a reference only in another task or inside an attachment is insufficient.
 These input references do not add execution dependencies or duplicate shared
 documents.
 
@@ -180,11 +187,18 @@ Read these attachments from that task before implementation:
 This task's `plan.md` owns its implementation plan and full acceptance criteria.
 ```
 
+When the shared architecture is inline, the architecture inputs instead identify
+the same source task ID and its description sections, such as "Upload flow" and
+"Error classification". Read those sections with `task show --json`; list full
+paths only for actual attachment documents that are also required.
+
 ## Preserve ownership and recover partial registration
 
 Stage briefs describe the work to produce the stage's outputs; they do not claim
-unfinished results exist. Every stage and delivery task has its own self-contained
-Markdown brief and detailed primary Markdown. Keep shared inputs at their actual
+unfinished results exist. Every stage and delivery task provides a task-specific
+Markdown brief and the complete applicable content, directly or through verified
+references. Complete inline content needs no primary attachment. Identify each
+task's own confirmation and evidence location. Keep shared inputs at their actual
 owner. Do not distribute a duplicate whole packet to every task. An independently
 needed snapshot records its purpose, original source, and source revision or
 content identity. Existing attachment reads support these references; do not

package/dist/commands/skill/skills/using-daynight/references/handbook.md

@@ -11,7 +11,7 @@ needed to use them correctly.
 |---|---|
 | `login` | Authorize CLI access through the browser using a device code. |
 | `logout` | Revoke and remove the current CLI credential. |
-| `setup` | Configure review repositories or explicit test-server/automation overrides. |
+| `review add-repo` | Configure a repository for review; review run/list also guide first-use configuration in an interactive terminal. |
 | `project create` | Register a repository as a project or find its existing project. |
 | `project list` | Find projects on the configured service. |
 | `project show` | Inspect a project's details. |
@@ -48,13 +48,17 @@ start login, retry anonymously, or blindly repeat a mutation. Reconcile an
 unconfirmed write before another mutation. Project discovery and explicit project
 IDs grant no access; current service membership decides authorization.
 
-For noninteractive automation, read `daynight setup --help` and use the explicit
-`--server-token-stdin` option with a token from a secret source. Never put a token
-in command arguments, chat, task descriptions, checkpoints or attachments.
-A token is bound to the normalized origin, and changing the origin removes its
-old local value. Credentials require HTTPS except for literal localhost or
-numeric-loopback HTTP. Setup saves configuration without network or login checks;
-ordinary setup does not prompt for a server address or token.
+For a test service or noninteractive automation, provision the existing
+`serverUrl` and `serverToken` fields in `~/.daynight/config.yml` through a trusted
+configuration or secret source. Omit `serverUrl` only for `https://daynight.cc`.
+Never put a token in command arguments, chat, task descriptions, checkpoints or
+attachments. Keep credential files private, with POSIX mode `0600`. Pair each
+credential with its intended normalized origin; when changing services externally,
+remove or replace the old token before another request. External file writes do
+not run CLI credential cleanup or participate in its write lock. Credentials
+require HTTPS except for literal localhost or numeric-loopback HTTP. File
+provisioning performs no network or login checks. There is no top-level `setup`
+command; `completion setup` remains the independent shell startup installer.
 
 **Project discovery.** Inside a Git worktree, task commands can omit `--project`:
 the CLI matches the origin repository URL to a project on the configured
@@ -137,9 +141,11 @@ version and timestamps, while stale versions still conflict. Status changes and
 `task list` and `task ready` accept `--allow-agents true|false`. The server
 combines that condition with other filters before pagination and the ready limit;
 an unfiltered ready page may contain tasks without automatic-execution permission.
-Automatic selection requires true and automated workflows must not enable it
-themselves. An explicitly user-selected task may still use manual execution regardless
-of the flag. Permission does not grant execution, publication or merge authority.
+Automatic selection requires true and does not enable permission itself.
+Only explicitly authorized [handoff](handoff.md) reviews the task against
+[the content standard](task-content.md) before enabling it; creation, breakdown,
+and execution do not do so implicitly. An explicitly user-selected task may still
+use manual execution regardless of the flag. Permission does not grant execution, publication or merge authority.
 A lost permission PATCH response is an unconfirmed write: read actual task state
 before reconsidering the operation, without resubmitting automatically.
 
@@ -211,15 +217,21 @@ explicit full relationship replacement; do not infer CLI append semantics from i
 whole supplied field. Preserve every still-needed value. Omitted fields stay
 unchanged; clearing and option-pairing syntax is in command help.
 
-**Markdown descriptions.** Write self-contained task briefs in Markdown following
-[create-task](create-task.md). The Web displays CommonMark/GFM, while API and CLI
-reads preserve the original string, including line breaks and fenced code. There
+**Markdown descriptions.** Write task-specific Markdown descriptions following
+[create-task](create-task.md) and [the task content standard](task-content.md).
+The description and actual references jointly supply the six requirements;
+complete inline content needs no primary attachment, and task-owned confirmation
+and evidence locations must be explicit. The Web displays CommonMark/GFM, while
+API and CLI reads preserve the original string, including line breaks and fenced code. There
 is no format flag. Relative description links and images start at the current
 task's attachment root; Markdown attachment internals start at their containing
 file's directory. Keep real case-sensitive paths inside the task root, confirm
 uploaded contents before linking them, and preserve Markdown and valid references
-when replacing a description. Shared inputs retain their source task ID and path
-or verified immutable repository URL; they are not cross-task relative links.
+when replacing a description. Shared inputs retain their owning task ID and
+content location: description with applicable sections for inline content, full
+path for an actual attachment, or verified immutable repository URL. Read source
+descriptions with `task show --json` and attachment contents separately. They
+are not cross-task relative links, and inline content needs no fabricated path.
 
 **Attachment independence.** Task reads contain no attachment inventory.
 Attachments use case-sensitive relative paths; uploads to the same path replace
@@ -236,9 +248,10 @@ create, establish identity from complete fields and operation context; a matchin
 title or an empty lookup alone is insufficient. Preserve actual errors and
 resource IDs rather than reporting success or blindly resending a write.
 
-Task registration, execution, and selection follow [create-task](create-task.md),
-[run-task](run-task.md), and [autopilot](autopilot.md), respectively. For a chain
-of independently tracked delivery stages, use [the Goal protocol](goal.md).
+Task registration, execution, selection, and requested handoff follow
+[create-task](create-task.md), [run-task](run-task.md), [autopilot](autopilot.md),
+and [handoff](handoff.md), respectively. For a chain of independently tracked
+delivery stages, use [the Goal protocol](goal.md).
 Every stage and delivery task follows the same todo/in_progress/done contract.
 A fixed Goal queue may use existing scoped execution authorization for its ready
 successors; registration and discussion confirmation grant no delivery execution

package/dist/commands/skill/skills/using-daynight/references/handoff.md

@@ -0,0 +1,102 @@
+# Handoff a task
+
+Use `handoff <task-id>` only when the user explicitly requests handoff of that
+task or a fixed set of tasks. This is a skill mode, not a CLI subcommand. The
+request authorizes content review and, after it passes, enabling `allowAgents`
+for those tasks. Creating, breaking down, or automatically discovering tasks does
+not authorize permission changes. Read [the handbook](handbook.md) for CLI
+operations and [the task content standard](task-content.md) for sufficiency.
+
+Handoff ends after review, any authorized permission update, and reconciliation.
+It does not start this session's run-task or autopilot, change status,
+dependencies or platform, or grant independent implementation, merge, mainline
+push, deployment, or external-communication authority. Existing execution and
+delivery authorization remains applicable to later scheduling.
+
+## Review the task and its sources
+
+Read the intended project and complete task, retaining its exact version,
+status, `allowAgents`, platform, dependencies, and worker record. Read the
+required source contents, including referenced source-task descriptions or
+actual attachments, and necessary further references under the content standard.
+Check current-stage sufficiency, responsibility boundaries, relevant
+producer/consumer contracts, and Goal delivery tasks' direct architecture index.
+
+For a `todo` task with permission false, organize its description or authorized
+source documents only from existing confirmed information. Missing decisions
+block review. Obtain user confirmation for material scope or behavior changes,
+then reread the changed description and affected actual sources. Unfinished
+prerequisites need not prevent handoff when the design and agreed interfaces
+already define the future work; preserve their real blockers and do not claim
+pending outputs are readable.
+
+Already-enabled tasks receive a read-only re-audit: they may be selected while
+review is underway. Do not assume they are paused or edit their content under
+that assumption. Follow the state rules below before any permission change.
+
+## State and ownership rules
+
+| Observed state | Handoff behavior |
+|---|---|
+| `todo`, permission false, review passes | Enable using the reviewed exact version, then reconcile. Dependency blockers may remain. |
+| `todo`, permission false, review fails | Keep permission false and report concrete gaps. Confirmed-information organization follows the review rules above. |
+| `todo`, permission true | Read-only re-audit; do not rewrite the same flag as an audit marker. |
+| `in_progress`, permission false | Report the permission lock; do not newly enable or reset status to evade it. |
+| `in_progress`, permission true | Read-only re-audit and report actual execution state. Review does not pause, stop, release, or transfer execution. |
+| `done` | Report completion and no handoff needed; do not reopen or update permission. This is mode policy, not an API prohibition on completed-task updates. |
+| Active or released worker record | Preserve ownership and execution history. A released execution can be `todo` but still needs confirmed original worktree/Agent continuity; enabling permission does not authorize a fresh execution elsewhere. |
+
+If an already-enabled task fails re-audit, report the failed review, actual flag,
+and continued scheduling exposure. Keep its permission unchanged. Revocation or
+stopping needs separately explicit scope and the established workflow, including
+running-task locks and worker controls. A failed review is not a successful
+handoff or an implicit suspension.
+
+## Enable permission and reconcile
+
+Finish authorized document changes and read them back before enabling permission.
+Recheck required mutable references against the contents reviewed; compare actual
+contents, not merely inventory or timestamps. Resolve changes before proceeding.
+Attachment writes and cross-task references are not atomically protected by the
+task version, and handoff does not provide server-side certification or freezing.
+
+For a reviewed false-permission `todo`, use the installed CLI's versioned
+`task update --allow-agents true` with the exact version on which the final
+review decision was based. A final description may be included in that same
+update. Omit unrelated options and preserve dependencies, platform, PR references,
+worker data, and other fields. Do not update status to make the task eligible.
+
+Check the write result and read back the complete task and required sources.
+On a version conflict, reread and reassess rather than merely replacing the
+version and replaying. If a write response is lost or uncertain, reconcile by
+reads only before considering any new mutation; do not automatically replay it.
+An unreadable reconciliation leaves the outcome unconfirmed: preserve the actual
+error and do not report successful handoff.
+
+Scheduling can claim the task immediately after enabling permission, so the final
+GET may show a higher version and `in_progress` with a worker. Report the actual
+observation; do not require equality with the update response's version or retry
+because execution was observed. Another writer may have set the same flag during
+an uncertain outcome. Without a confirmed write result, report only the observed
+state rather than attributing the change to this operation.
+
+If final source verification fails or reveals material changes, report review
+incomplete or failed and the actual permission/state, including continued
+scheduling exposure when true. Do not claim success or automatically revoke the
+flag. Further action follows the same explicit authorization and state rules.
+
+## Report and return
+
+Read back the complete task before reporting, including read-only re-audits.
+Reassess changed review-relevant metadata or sources; a newly observed worker
+claim is reported under the state rules rather than treated as proof of failure.
+Report each task's content-review result, changes or concrete gaps, observed
+version, permission and status, remaining dependency blockers, and applicable
+worker-continuity constraints. Distinguish a confirmed permission update from an
+uncertain write and a read-only re-audit. Permission true alone proves neither
+execution started nor completion; report either only from actual evidence.
+
+For a fixed set, review and report each task separately; one pass does not cover
+other tasks. Return without selecting work or starting execution. The flag is
+not a durable review certificate, and this mode does not bulk-rewrite existing
+permission values.

package/dist/commands/skill/skills/using-daynight/references/run-task.md

@@ -10,15 +10,19 @@ it is not automatic backlog selection.
 ## Establish the task and stage
 
 Read the complete task with `daynight task show <task-id> --json`. Its Markdown
-description must make the problem, current actions, scope, deliverables,
-constraints, and observable completion summary understandable. Read its own primary
-Markdown's Solution and Acceptance criteria; equivalent headings in the task's
-language are valid.
+description must identify the concrete current work, responsibility, and content
+sources. Read it and its actual required references under
+[the task content standard](task-content.md), including the solution, acceptance
+criteria, and explicit task-owned confirmation/evidence location. Complete inline
+content needs no primary attachment; document-owned and mixed organization are
+valid when the combined contents satisfy the same six requirements.
 Resolve description-relative links and images from the current task's attachment
 root; links inside a Markdown attachment use its own directory. Resolve real
-shared input references using the source task ID and attachment path or a verified
-immutable repository reference. Read required contents rather than assuming a
-task read loads attachment inventory or bytes.
+shared input references using the owning task ID and description/sections,
+complete paths for actual attachments, or a verified immutable repository
+reference. Read source descriptions through `task show --json` and actual
+attachment contents through the attachment commands; a task read does not load
+attachment inventory or bytes.
 
 For a Goal stage or delivery task, read [the Goal protocol](goal.md) and identify
 its role from the actual task content and context. Apply that stage's input and
@@ -26,9 +30,10 @@ output requirements. Requirements and solution discussions start from their stag
 the completed requirements, applicable UI prototype, and architecture are outputs
 of the stages that produce them. Delivery tasks require the delivered design and
 applicable prototype. Before implementation, read every required architecture
-document listed in the delivery task's description using its architecture task ID
-and full attachment paths or verified immutable repository references. This also
-applies when the architecture task is only an indirect prerequisite. Confirm the
+source listed in the delivery task's description: the owning architecture task's
+inline description and applicable sections, full paths for actual attachment
+documents, or verified immutable repository references. This also applies when
+the architecture task is only an indirect prerequisite. Confirm the
 description's references satisfy the Goal protocol. When a prototype is a required
 input, view and exercise it with its resources. An unfinished output of the current
 stage is not a missing input.
@@ -54,12 +59,11 @@ express same-chain prerequisites, external marks distinguish verified cross-chai
 ownership. Both kinds must be done before entering in_progress or done. Classification
 never grants permission to execute a prerequisite, enable automatic
 execution, or remove a blocker.
-A missing or unreadable primary Markdown, missing Solution or Acceptance criteria,
-or missing or unreadable required architecture reference or input leaves execution
-unready. Resolve it within the existing authorization or return the concrete issue.
-Do not infer requirements from a title, silently invent acceptance criteria, or
-move detailed plans into the description. Do not execute prerequisites as an
-implicit expansion of the requested task.
+Missing required content, an unreadable required source, or a missing required
+architecture reference or input leaves execution unready. Resolve it within
+existing authorization or return the concrete issue. Do not infer requirements
+from a title or silently invent acceptance criteria. Do not execute prerequisites
+as an implicit expansion of the requested task.
 
 Creation leaves a task `todo` and does not execute it. An explicit request to
 start the current Goal discussion, or the user-directed transition that starts
@@ -109,15 +113,16 @@ updates; confirm new or replaced resources before linking them. Dependency edits
 must follow the handbook's CLI replacement contract: read full D/E, retain needed
 ordinary D−E and external E declarations, submit their intended complete sets
 with the observed version, and read back both. Omit all dependency options for
-unrelated metadata updates. Each primary
-Markdown owns its detailed plan and evidence; shared inputs remain at their
-verified source.
+unrelated metadata updates. Keep detailed content at its identified owner and
+confirmations and evidence at their explicit task-owned location; shared inputs
+remain at their verified source.
 
 Advance only this task. Subagents collaborate on it, and waiting for CI, review,
 approval, or merge remains part of it. Keep all required delivery PR URLs and
 titles in the complete `properties.pullRequests` list, preserving existing
 entries. Record acceptance results and necessary delivery evidence, including
-merge commits, with the primary Markdown's corresponding acceptance criteria.
+merge commits, at this task's identified evidence location against the
+corresponding acceptance criteria.
 Rewrite current evidence coherently rather than accumulating an execution log.
 Keep operational progress, blockers, waiting items, and next action in the
 conversation or existing execution checkpoint, retaining the task ID and needed