saubakirov/trace-first-starter/daily-task

TFW Daily Task

Mindset: Work backwards from the result the person needs. State Goal and Value; test them against the receiving project's North Star and Values. Challenge a weak premise with concrete reasons. Use consequential Questions and Saint-Exupéry judgment: remove work that protects no purpose, evidence or boundary. Daily names this bounded route, not a cadence or risk rating.

Authority: One actual worker performs the work the human's clear bounded request authorizes. The human retains purpose, accountability and acceptance. This optional route is outside formal Full task work; it grants no Coordinator, Executor or Reviewer authority in an active formal task. Title, model, profile, prior task and apparent urgency grant no permission.

1. Inspect before action

Read the applicable project instructions, personal preferences when present, existing Daily rules and actual request source. Follow local identity and record rules. Record the actual human and worker/source; disclose missing identity without inventing a handle. A missing profile alone does not block work when the actual request and authority are established. Missing request source or legitimate authority blocks the dependent action.

Inspect the current object and its governing product/document sources before historical work. Make one bounded search using the object's path, name or intended result in relevant recent Daily records and current project knowledge. Read convincing matches only. Record inspected paths and commit, hash or observed state; an honest no-match is enough. Check older work's scope, currentness, source, producer and authority. Resolve material successor/conflict relations using the project's existing knowledge rules. History never overrides current product truth merely because it is related.

Before the first material product write, retain an observable checkpoint in the selected record: actual source, inspected rules/current object, prior-work lookup/result, Goal, Value, North Star fit, Boundaries and completion oracle. Do not retrospectively claim this gate ran. The checkpoint is a compact statement of observations and decisions, not private reasoning or a questionnaire.

2. Bound and select the record

Check whether the requested object belongs to an active formal task/phase or another mutation owner. For formal Full work, stop its dependent change and return to that task's existing Coordinator and approved role route; do not alter formal controls, invent a verdict or relabel it Daily. Explain the exact missing authority. Consequence and uncertainty determine checks and independent review. For a material goal/boundary change or reserved release, publication or communication, retain the prepared work and route the specific decision to its existing authority. Silence is never approval. Perform independent authorized preparation when a separate effect is blocked.

Continue an existing record only when this request revises the same bounded deliverable under its still-governing authority. Preserve prior request meaning, result and material decisions through dated additions, justified versions or ordinary file history. A separately accepted outcome, owner or boundary gets a separate record. Add exact Related links only when they affect a decision; no mandatory category, shared journal, backlink maintenance or archive-wide sweep.

Honor the receiving project's established form, including a three-file task/brief/messages split. Otherwise create daily/YYYY/YYYYMMDD-HHMMSS_slug/task.md using the Daily-owned .tfw/extensions/daily-task/templates/task.md. Read the clock once; use the whole immutable folder name as ID. If occupied, add a distinguishing suffix without changing or moving the existing record. Keep products at their ordinary project paths. No daily/README.md, formal HL/RF/status/journal, new lifecycle vocabulary or per-task knowledge file is required. Do not adopt a no-folder alternative by implication. Where title write and readback are supported, use DAILY · <exact folder ID>; otherwise disclose unavailable control once and continue authorized work. Navigation grants nothing.

3. Execute and check

After those internal checks, complete the bounded work without a second HL/brief approval or generic question sequence. Resolve routine gaps from inspected sources. Ask only for a missing consequential fact/choice/authority and hold only its dependent action. Record material human words as exact selected excerpts with author/source; do not copy every message, secrets or private reasoning.

Use the focused check that tests the actual completion condition: run the repaired function in its local application, open/read the finished document, or inspect the design in its real format. Preserve a previous result when the request protects it. Distinguish observation, inference and uncertainty. A source inspection or install hash proves only that level, not native host behavior. If a check fails, fix within the boundary and recheck affected claims; a required unavailable check keeps its claim open. Never invent acceptance, release or an unobserved effect.

4. Leave the selected Trace and return

Update the selected local record with result paths, material decisions/revisions, actual checks and limits, and the authoritative next action or an actually accepted close. Prepared, checked, human-accepted and released are different claims. Make source, Goal/Value, Boundaries, current result, check and next authority recoverable without the original chat. A checked result awaiting its human acceptance must say so.

Retain a consequential reusable observation as a Fact Candidate only with source, scope and uncertainty. Stable rules belong in existing product documentation or the project's authorized knowledge route; repetition alone neither proves a fact nor authorizes publication. Return the usable result and any specific remaining decision. Do not leave authorized work unfinished merely because a record exists.

Installation/update is separately governed by installation.md; do not preload it for ordinary work.