This playbook takes a project from its actual starting state to a team that can begin the authorized work with a shared goal, engineering policy, knowledge graph, resource ownership and a truthful account of custody coverage. Use it for a new project or adoption by an existing project. The starter assignment can be given to another agent. The worked case is Tekton on 2026-10-11, from its research-only directory through the human’s instruction to onboard developers and start implementation. The complete channel was read: 21 root messages and 129 replies across all 10 threads, captured at 19:33:21 UTC. This is a dated retrospective, not a live status page for Tekton. The source map provides exact retrieval commands and the boundary of the evidence. The result was implementation authorized and begun; custody initialized-limited. Neither a complete product nor the full custody protocol was demonstrated. “Pushed to implementation” describes the phase transition: the project was still local, with no remote publication reported in this cut.

​
What the initializer must deliver

Deliver one coherent, reviewable project setup with these properties: Preserve this chain throughout initialization and later work: The diagram describes the required relationship between sources. It does not assert that every arrow is enforced by an installed Desk version. Git owns code state; Channels owns source messages; the human owns their directives; the project owns its accepted policy; custody records their relationships and observations. A copied summary cannot acquire the authority of its source. If custody-genesis-skill is installed, read its SKILL.md and adjacent CUSTODY-GENESIS.md. The Tekton process used version 0.2.2. That package defines the detailed C1–C12 contract, G1–G8 workflow, P01–P74 engineering rules and versioned Desk adapter. This playbook explains how to apply the process and improve the handoff; it does not silently revise that package. Discover its installed location instead of assuming another machine’s home directory. If it is unavailable, the workflow below remains usable, but do not claim completion of that skill’s full rule reconciliation without reading its rules. Current project instructions take precedence over a reference workflow. Make material exceptions explicit at the existing policy owner; do not introduce another approval system or compliance database.

​
1. Discover the project and the current assignment

Read the human’s actual request, applicable repository instructions, current roles and source decisions before proposing a setup. Determine whether this is a new project, adoption, recovery or a repair of an existing binding. Separate what is authorized now from possible future work. Inspect the actual directory. In a Git repository, useful reads are:
Record the baseline commit or explicitly absent HEAD, branch, staged, unstaged and untracked work, active writers and known other clones/machines. Do not expose credentials embedded in remote URLs. A local worktree listing does not discover every clone or prove recovery coverage. For adoption, retain existing history, identifiers, rules, knowledge paths and in-flight work. Record an adoption boundary and unknown earlier coverage. For a new project, do not inherit a similarly named remote, old rules or old results without a decision making them applicable. Initialize local Git when authorized; never invent a baseline commit while HEAD is unborn. For channel-based discovery, read the root and every relevant thread. For genesis or an explicit whole-history review, read all threads. Root output contains thread pointers rather than the replies themselves:
Replace the uppercase markers. Follow any further thread pointers, check for truncated output, and retain a source cutoff. A notification summary is an entrypoint, not the full conversation. On a busy channel, reread the owning thread and current human corrections before taking an action from an old notification. Routine later changes need the applicable source closure, not another complete project audit. Tekton lesson. The initial directory contained four research documents and no Git repository. An agent proposed adopting an older repository with a similar name. The human explicitly chose a new local project instead, with another repository only a future integration candidate. The initial mission also arrived as quotations in an agent’s earlier conversation, without the original message IDs. The team retained that provenance gap rather than manufacturing primary human sources. See T1/T4 in the source map.

​
2. Interview for the missing choices

Ask one to three focused questions per round. Give coherent options, a recommendation and the consequence of each option. Reuse answers and standing permissions already supplied; do not make the human answer the same question in different terminology. When methodology is undecided, ask the initial engineering questions before writing a rulebook or investigating optional runtime infrastructure. Use the agreed language and decision surface. Tekton explicitly required Russian discussion and one thread per topic. That local choice took precedence over a template that preferred root-level decision requests. Questions must still be visible to the person who owns the answer. Keep each material decision together with its scope, source, owner, rationale, applicability and replacement condition. Distinguish human-decided, existing-policy, agent-delegated, proposed and unresolved. These are descriptive labels, not runtime authorization fields. When using the genesis skill, reconcile all P01–P74, including conditional rules and prohibitions. Group the discussion and record dispositions in the canonical engineering policy; a 74-question interview or separate tracker is unnecessary. Do not claim a missing mechanism is conditionally inactive merely because implementing it is inconvenient. The grouping is an interview coverage map, not a substitute for those full rules. Existing policies may retain, adapt, explicitly except or conditionally deactivate a rule; record the source and activation condition. Leave genuinely unresolved choices visible. Tekton lesson. The human selected production-only behavior verification, forbade unnecessary validators, guards, tests and governance, delegated team consensus, and limited escalation to significant architecture changes. The team correctly adopted those answers instead of its original recommendation. These choices belong to Tekton; they are not universal requirements for the next project. Requested genesis documentation remained in scope. T2/T3/T4a.

​
3. Establish one goal and a usable acceptance contract

Write or reuse the canonical goal early, before detailed planning creates competing copies. Preserve the full mission alongside the first achievable result. A narrow first scenario must not erase the rest of the requested system. Conditional later integration stays conditional. A useful goal document answers:
  1. Who supplies the real input, and what complete result do they receive?
  2. How does the next operation consume the result, including saved state and recovery where required?
  3. What is the first complete scenario, its assumptions and explicit limits?
  4. What constitutes success, failure and insufficient evidence?
  5. Which acceptance thresholds are agreed, which remain open, and who may change them?
For each KPI, specify the quantity, units, population/denominator, conditions, threshold, observation boundary and acceptance owner. Include unsuccessful attempts and end-to-end cost. Separate a chosen target from a measured result. Names such as “robust,” “large” or “accurate” need an observable interpretation. For research, choose comparisons and data splits before evaluating results. Separate acquisition from data admission, synthetic labels from independent evidence, and source-informed transfer from a blind holdout. Retain negative and incomplete results. Resource arithmetic should expose infeasibility early; it cannot justify dropping inconvenient cases after seeing their outcomes. Tekton lesson. Historical reports showed a benefit on one class of physical failure but not on all failures. The team therefore required multiple repair locations, comparable complete budgets and all failures in the denominator. It inspected candidate datasets instead of treating a file called “mesh” as a usable engineering input. A JSON result could not be linked to the selected calculation input, so it was not promoted to ground truth. The agreed numerical formulation became an accepted, unexecuted definition of what to implement; its acceptance did not establish numerical accuracy. The first evaluation plan implied at least 4,608 neural requests. A 36-hour allocation allows 28.125 seconds amortized per request before additional comparisons; 600 seconds on every sequential request would require 768 hours. Recording this prevented a latency ceiling from masquerading as a feasible schedule. An incomplete series would remain inconclusive. These numbers are case evidence, not defaults for another project. T5.

​
4. Give each fact one canonical home

Reuse equivalent existing documents. A compact new-project arrangement is: Git remains the live owner of checkout state; Channels remains the owner of assignments and source decisions; execution stores own actual run evidence. Do not create parallel manually maintained worktree, task, role or event logs. Add further concepts only for distinct scope or authority that the project needs. A small bundle does not need a forest of empty directories. When moving a contract, replace normative duplicates with links in the same change. Preserve historical sources and supersession. Updating a document digest without updating its actual bytes, or vice versa, leaves a misleading binding. Date evidence explicitly: a historical “no HEAD” observation must not be read as the current Git state after implementation starts. Tekton lesson. GOAL.md became the sole owner of numerical criteria; architecture retained formulas, data and experiment method. Genesis linked GOAL instead of copying it. Establishing that ownership earlier would reduce later migration work and opportunities for competing edits. T6/T7.

​
5. Build a small, traversable OKF graph

Pin the specification and the project’s profile. Tekton used OKF 0.2 at 58b3370. Concept identity is its bundle-relative path without .md; a concept has YAML frontmatter with type. generated is one mapping, sources is a list, and verified records actual verification. Preserve unknown types/fields. The reserved index.md and log.md are not ordinary concepts. Additional required metadata and vocabulary belong to the chosen project profile. This illustrative knowledge/genesis.md links canonical owners. Replace the actor, timestamp and source with actual facts before use:
The body explains scope and provenance and links the real design. Each named concept must exist and point to its actual policy/resource. A root index for this profile declares okf_version: "0.2" and provides navigation. Do not invent verified: human:... because an agent reviewed the package. applicability, depends_on, authority_refs, active_gate, superseded_by and resource_digest are Desk/project extensions, with semantics owned by the adapter/profile. Ordinary navigation does not assign work or make a rule applicable. Confirm the actual traversal reaches required concepts, canonical resources and their exact versions. An external source URL is a declaration; it does not prove that Desk fetched it or that the agent read it. Validate metadata shapes as well as reachability. A permissive parser can preserve invalid provenance without identifying the error. Missing required targets, exhausted traversal limits and ambiguous relationships must remain visible. status: stable describes the standing of a concept, not achieved KPIs or runtime readiness. See project custody configuration for current selection and traversal limits.

​
6. Bind the installed runtime and verify the recipient

Inspect the intended Desk instance, manifest and installed implementation. Use supported project editing and preserve all unrelated projects, groups and durable sessions. Do not restart a shared instance or replace its manifest as a shortcut. A desk init invocation is not custody initialization. This is a partial project entry, not a complete manifest:
Choose a new stable repository identity once, or reuse the existing one. Do not copy Tekton’s UUID, channel or session names. repositoryId is not automatically a GitHub database ID or a runtime-issued anchor. Roots select where concepts belong; genesis selects traversal seeds, not every file under those roots. Observe actual runtime-issued IDs rather than inventing hashes. Bind each participant’s actual project, durable session and checkout. A channel can contain agents from different projects. A Desk maintainer in the room may correctly receive an unbound Tekton genesis. Conversely, one successful recipient proves nothing about newly added developers or worktrees. After those are introduced, verify their effective bindings separately. Use a substantive, already-authorized message/assignment to observe ordinary delivery; do not create acknowledgment loops. Read the recipient’s actual anchor. Check repository identity, checkout, source versions, applicable rules, coverage and diagnostics. Distinguish Recorded context from Current context: a later correction must not rewrite the earlier record. Reading an anchor is neither a delivery receipt nor proof of comprehension. Rollback of a binding uses the supported project edit; custody: null removes that binding. It does not delete Git, concepts or historical records. Preserve previous configuration and unfinished operation state for recovery. Tekton lesson. The supported project edit returned HTTP 200. A subsequent ordinary delivery to codex contained a bound genesis with 10 nodes, 28 relationships and complete: true for reachable-okf-and-direct-resources. This demonstrated selected working-tree capture even without HEAD/index. It did not establish sender enforcement, all-worktree recovery or complete project history. The other initial agent belonged to Desk and remained unbound to Tekton. T4, historical anchor in the source map.

​
7. Assess the complete protocol, not just the graph

Separate four facts: required, configured, observed, and accepted. Record capability results as passed, failed, blocked or not-run, with their scope and evidence. Optional features can be not-applicable with a reason; an absent required capability remains a gap. Use these readiness terms consistently: The following is the minimum coverage map for a full custody claim. It also states what the Tekton genesis actually established at the reviewed boundary.

​
Publication is a distinct boundary

The required order is: resolve sender and work scope → retrieve/deliver its applicable context → compose the draft → revalidate relevant freshness and identity → atomically retain message revision and provenance → resolve the notification anchor → deliver recipient context. Check valid publication and negative cases: absent or fabricated proof, wrong session/project/generation, relevant rule changed after preparation, incomplete sources, edits/share/direct RPC, and crash/retry. Unrelated source changes should not force a global restart. Preserve drafts and existing idempotency. Human instructions and Stop must remain usable during degraded agent context. These are observable requirements, not permission to invent an API field, a custody prepare command or a local bypass wrapper. At the reviewed Desk implementation, recipient context was prepared after message persistence. Voluntary reading, a reminder, a signed package or traversed: true in a request could not establish the missing sender gate. Issue #204 documents the actual write paths and reproductions. Recheck the installed build and current issue before treating that historical gap as present or fixed. This playbook does not implement a fix.

​
Verification must match the chosen engineering method

Exercise supported real boundaries with authorized, reversible operations. If the project permits isolated fixtures, keep them away from live team traffic and resources. If it requires production-only verification, do not smuggle a prohibited harness into the task. A behavior that cannot be safely exercised stays not-run or blocked; a schema check cannot replace it. For selected remote features, establish actual repository/Project identities, field owners, allowed readers and outgoing effects. Verify missed/out-of-order input, duplicates and an unknown outgoing result under the same operation ID. A successful direct gh mutation is not proof of managed custody routing. For archive/recovery, establish one logical writer, retained outboxes and verified remote records and payloads. Check relevant staged/untracked, ignored-file, LFS and submodule coverage. Restore to a new destination using the archive with the fixture source unavailable; do not destroy the real project. Writer transfer needs fencing, not a UUID edit. Follow the installed journal and peer contract. Automatic custody capture and an optionally adopted protected OKF governance journal have different jobs. Do not invent a handwritten knowledge/log.md, okf-journal or frozen-candidate procedure to fill runtime gaps. If such a procedure is selected, qualify its append, concurrency, protection and recovery behavior; a created ref proves none of them. Missing full-protocol coverage prevents a ready claim. It does not cancel independently authorized product work. Hold only actions that actually depend on the missing capability, identify the implementing owner, and continue the useful permitted work.

​
8. Form the team around real implementation connections

First identify the full path and its currently missing producer/consumer connections. Assign owners, not just titles. Each bounded assignment includes the parent objective, exact write set, interfaces, dependencies, authority, acceptance and next integration owner. Useful functions include integration/priority ownership, domain or scientific reasoning, and implementation of independently ready connections. Combine functions when one agent can do them effectively. Keep a separate protocol maintainer only when it has a real assigned job. Do not infer that an existing custody agent should become a product developer or scientist. The operator’s actor restrictions are binding. If the human will create agents, publish the proposed responsibilities and wait for those actual sessions. A role description is not agent creation. Once created, match handle, durable session, project, checkout and effective role/functions; confirm in real recipient context. A chat reminder alone does not configure the roster or prove native execution identity. This is a reusable concise reminder; substitute the actual scope:
Tekton lesson. Successive proposals incorrectly assigned the Desk maintainer scientific/product work and omitted dedicated developers. The human settled four total agents: two developers, codex combining Scientific + Team Lead, and codex-2 limited to Desk/custody analysis and remote issue documentation. That correction was an actor restriction, not a request for more consensus. Four agents, their handles and their domain specializations must not be copied automatically into another project. T7.

​
9. Hand off ownership safely and start only the authorized phase

Read the latest owning thread and Git state immediately before writing. Announce potentially overlapping work. Once another writer has claimed a resource, coordinate one owner; unilateral competing claims do not resolve ownership. A file changing between reads is a collision alarm. On collision, stop writes to that resource, disclose the actual current version and unfinished commands, and let one named owner reconcile it. Do not overwrite, reset or delete the other version to make the tree clean. Avoid reciprocal ownership transfers in queued messages: name one final writer and an explicit handoff point. Before concurrent code writing, establish a permitted baseline and isolated attached branches/worktrees with disjoint write sets. Preserve authored history under the adopted integration policy. Do not invent human authorship when Git identity is missing; resolve it consistently with project policy. Give the shared environment, expensive processes and integration one owner. Do not operate another owner’s cloud resources. Onboard each implementer with the goal, current authority, applicable rules, actual checkout/baseline, bounded assignment, interface contracts and a current custody context command. Agree on semantics, units, state identity, failure, persistence and restoration between producer and consumer before dependent implementation. An API shape alone is not a completed connection. Keep these phase statements distinct: Reuse valid implementation authority through ordinary corrections and integration. Do not add a ritual approval after every step. Conversely, a request for research, genesis or role reminders must not expand itself into implementation, experiments or remote publication. Tekton lesson. An architecture/rules discussion was misread as permission to implement. Five unexecuted draft files appeared; the human stopped the work. Those files were preserved and disclosed. Only the later instruction to onboard Dev1/Dev2 and officially start implementation supplied the next phase’s authority. The lead then assigned disjoint files, made local baseline 52918670357b7784bc59a5c49df2c5f211d0283e, and created separate development worktrees. CPU package import was reported separately from the unrun GPU evaluation. The human’s later standing Runpod instruction also required respecting pod ownership; it did not make another agent’s pods available. T5/T7/T8 and root resource instructions in the source map.

​
10. Close genesis with one useful handoff

Review the concrete package once for contradictions, omissions, duplicate owners and unsupported claims, under the chosen workflow. Where an independent founding review is required, use an authorized reviewer or the human; a writer’s self-check is not independent review. Fix findings and check the corrections without reopening settled decisions. If the required review is unavailable, record that limitation honestly. The handoff should fit in one substantive message with links to the actual files and evidence. Use the existing canonical record for the detail:
Do not turn the handoff into a second live status registry. On resumption, read current source decisions and Git/runtime state; reconcile changed bindings without recreating identities, keys, channels or history. Update only affected rules and evidence. Keep protocol maintenance tied to real team needs.

​
Failures to avoid, with the corresponding improvement

The delayed notifications were also a confirmed Desk defect, not solely a conversational mistake. In the live delivery records, an 18:48 message was submitted to the recipient at 19:09 (20m56s), and the human’s 18:58 role correction at 19:13 (14m51s). Provider-pending submissions escaped Desk’s digest aggregation; stale-delivery wording was prepared before the wait at the provider. An isolated production-engine reproduction retained three individual provider submissions while Desk’s queue depth was zero. Existing 25 targeted tests passed, showing their coverage did not catch the behavior. #206 contains the witness, source analysis and acceptance criteria. It was documented, not fixed by genesis. It does not excuse missing a prior claim in the current thread or prove every collision was caused by the queue. For a newly observed protocol defect, reproduce the actual team conditions, check existing issues, and document expected/actual behavior, exact build and source, evidence, impact and a falsifiable correction criterion in the authorized remote. Do not patch another team’s product as a side effect of protocol QA, or make that investigation block unrelated product work.

​
Assignment for the next initializer

Fill in only the facts already known. Leave real questions for discovery and the interview; do not copy the Tekton answers into the new project.

​
Source map and review boundary

The following thread IDs locate the entire reviewed conversation, not just selected supporting replies. Dates/times are UTC. Commands operate on the owning Desk Channels home; these local message IDs are not globally portable GitHub links. This document contains the reusable conclusions, so a new project does not need access to Tekton’s channel or research files.
Important authority transitions are individually retrievable: The historical recipient observation is retrievable with:
Its recorded genesis is genesis-971feb290ff1983013a9c4bb233d7cfeb15a03870c9177e7b76331c3cb551b01. The counts in this playbook describe that historical observation, not its current lookup result. The case was also checked against Tekton’s committed founding documents at 52918670357b7784bc59a5c49df2c5f211d0283e and an actual three-worktree listing. Subsequent implementation progress is outside this retrospective’s acceptance claims. The full channel transcript was read for this review; cited research results remain historical reports. No new Tekton training, physics validation or recovery experiment was run for this document. Remote Desk issues #204 and #206 were open when checked. Installed-source investigations referenced Desk 6e353f0bf839387a35bb37d2959556ff624f0ecc; this documentation is prepared on ae24047ac9694be887df291761fd2a5ff9abaffc. Consult current implementation and evidence before claiming those limits changed. Related contracts: Channels protocol, configuration, custody design, implementation status, and Desk engineering rules. The design and this process state requirements; only observed implementation behavior establishes support.