Project task ledgers
Use this method to maintain durable project-task records for customer delivery and internal work. A ledger records tasks, owners, blockers, optional due dates, review waits, request traceability, evidence, and implementation commits. It is not a sales CRM, a personal todo list, or a substitute for the system that owns raw feedback.
Resolve every read or write through `./references/host-operations.md`. Do not assume a repository path, helper command, calendar provider, named reviewer, or organization-specific project structure. If the host cannot authorize a write, return the proposed task changes with their evidence and intended destination.
Modes
| User intent | Mode | Reference | |---|---|---| | Create a project ledger | `init` | `./references/ledger-format.md` | | Capture tasks from supplied material | `capture` | `./references/capture.md` | | Change status, owner, blocker, evidence, or next action | `status` | `./references/status.md` | | Report one project | `report` | `./references/report.md` | | Summarize active work | `summarize` | `./references/summarize.md` | | Draft a customer update | `customer-summary` | `./references/customer-summary.md` |
If a request could read or write, ask once before writing. A clear, authorized write request may proceed after ambiguity and duplicate checks.
Core workflow
1. Resolve the project and read its existing ledger through the host project ledger operation. 2. Preserve the source, request wording, relevant source identifiers, context, owner, next action, blocker, due date, and evidence for every request-driven task. 3. Identify new tasks, safe updates, duplicates, and ambiguities. Ask before creating a record if the project, task owner, status, or requested change is unclear. 4. Apply an ordered batch through the host operation; do not edit generated status tables by hand. If `project_ledger.commit` is bound and separately authorized, call it after a successful write batch; otherwise keep the completed records distinct from proposed changes. 5. Report added, updated, skipped, and unresolved items with the resulting ledger location, revision status, or proposed update batch.
Data model and evidence
Use the status model and field rules in `./references/ledger-format.md`. Keep the request trail until completion. `Done` requires evidence. When tracked code satisfies a task, record commit identifiers alongside—not instead of—broader evidence.
Use an explicit approval field only when the source or user requires approval. When approval is required, completion needs both normal evidence and approval evidence. Read `./references/approval-watchdog.md` for customer-visible and high-consequence work.
Boundaries
- Do not create CRM records, personal todos, or raw feedback records. - Do not send messages, publish content, schedule reminders, or make external changes merely because a task has a due date. - A customer-ready summary is a draft unless the host separately authorizes its delivery. - Keep implementation evidence tied to the original request; a commit ID alone is not sufficient proof. - Use named roles from the host record, not hard-coded people or addresses.