A preserved method from https://github.com/mattpocock/skills at 3cca18b368ae, path skills/engineering/implement, MIT. 28 of 20 source lines differ (140%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, pull-2026-09-11, fold-2026-09-11, series-s7-roster-2026-09-11, vocabulary-owner-2026-09-12, roster-keepers-2026-09-15, light-path-negative-2026-09-15.
greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: implement
name: "implement"
description: "Implement a piece of work based on a spec or set of tickets."
description: "Build one frontier ticket in a fresh context, or make one settled fix with no ceremony on the light path. Use for 'build TKT-NNN', 'next ticket', and small clear changes: fix, add, rename, adjust."
disable-model-invocation: true
---
---
scopechangedvocabulary-owner-2026-09-12
one opening paragraph in the skill's voice: fires on 'build TKT-NNN', 'next ticket' and a small clear change; shaping goes to grill-with-docs, planning to to-spec and to-tickets, review to delivery-review, proof to verify-this; never reviews its own result or settles an open consequential decision (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
Implement the work described by the user in the spec or tickets.
This skill builds one ready ticket, or makes one settled fix on the light path. It fires on "build TKT-NNN", "next ticket", and a small clear change: fix, add, rename, adjust. An open product question is not settled here: it goes to grill-with-docs, and a plan to to-spec and to-tickets. The independent review belongs to delivery-review and the proof of acceptance to verify-this; this skill never reviews its own result, and a consequential unresolved decision returns to the owner with evidence rather than being decided during the build.
lifecyclechangedlight-path-negative-2026-09-15
the work is one ready ticket from greenline status (a compact ticket for a settled change without one, none on the light path of one source file and its test with no open choice, whose failing test, if any, already names it; a test red before the work starts that does not name the change makes it not light, a red test written for the change does not count, and an instruction the change cannot keep is an open choice), read with the pinned revisions in its consumes, claimed with claimed_by and base_commit; carried from roster-keepers-2026-09-15 (J-13, 2026-09-15)
Use /tdd where possible, at pre-agreed seams.
Implement the work described by the user in the spec or tickets. The work is one ticket: `greenline status` lists the ready frontier, and a settled change that has no ticket gets one compact ticket with intent, scope and falsifiable acceptance as `.greenline/WORK.md` defines it, except on the light path, where a change confined to one source file and its test, with no open choice, whose failing test, if any, already names it, takes fix, checks, one commit and the reply, with no ticket, account or review; a test red before the work starts that does not name the change makes it not light, a red test written for the change does not count, and an instruction the change cannot keep is an open choice. A change across files is never light. Read the ticket and the actual revisions in its `consumes`; a stale input is reassessed before dependent work. Claim it with `claimed_by` and `base_commit`, and create the implementation account as `.greenline/ledger/README.md` defines it; a ticket already claimed or implementing under your own claim is a resumption, so read its reviews and the commits since the base and continue what remains. An existing ticket keeps its global ID and evidence home. Follow the retrieval loop in AGENTS.md before the first edit, respecting the touched roots' decisions; guidance delivery facts come from generated receipts, and you add only the meaning and result evidence. Preparatory upkeep belongs to this same contribution.
renamechangedfold-2026-09-11
bare roster name in prose: /tdd is tdd; the same rename as before the fold, remeasured because the surrounding lines moved
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
Use tdd where possible, at pre-agreed seams.
locationchangedfold-2026-09-11
the checks' captured commands and outcomes live under .greenline/work/evidence/TKT-NNN/ and are referenced from the account's checks; a failed or unrun check stays visible and quantified acceptance needs evidence covering the stated set
Once done, use /code-review to review the work.
Run typechecking regularly, single test files regularly, and the full test suite once at the end. Keep each captured command and its outcome under `.greenline/work/evidence/TKT-NNN/`, referenced from the account's `checks`, and keep a failed or unrun check visible. Quantified acceptance needs evidence covering the stated set, with any explicit exceptions accounted for; a sample cannot prove an exhaustive claim.
methodchangedvocabulary-owner-2026-09-12
upstream reviews before committing; greenline commits the coherent result, finalizes the account, then requests one bounded delivery-review of the committed ticket (the block, step 5; the S6 QA fix the operator approved on 2026-09-11), so this hunk changes the method order Confirmed by the operator on 2026-09-11 (method-rulings.md). The same paragraph now names the two tests of a durable decision (a convention other code must follow; a trade-off beyond the acceptance) and allows an offer, a scope sharpening from the S7 series. (carried from series-s7-roster-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
Commit your work to the current branch.
Once done, commit your work to the current branch: the coherent implementation result, with `result_commit` recorded on the ticket and the ticket at implemented. Then finalize the implementation account with that exact `resultCommit` and commit it separately; the accounting commit is a review input of its own and does not extend the implementation range.
Then request delivery-review of the committed ticket, its account and `base_commit..result_commit` through an available subagent tool, giving the reviewer the relevant contracts and retrieval access: one bounded round, part of the authorized work, not an owner relay. The reviewer writes the review record when it takes the ticket from implemented to reviewing. Findings return to this claim; rework changes the result and reopens affected checks, review and verification. The findings and any rework go to the owner with the reply, and a further round waits for the owner's word. When no delegation tool is available, record that limit in the account, leave the ticket implemented and blocked for review, and reply; the owner can open a fresh reviewing session. Before the ticket closes, evaluate whether the work surfaced a durable decision: a convention other code must now follow, or a trade-off accepted beyond the ticket's acceptance, is one even when an existing decision dictated the behaviour; record it with record-architecture-decisions in the established home, or offer to, or state plainly that none was needed. The ticket completes only when its acceptance, the independent review and the verification are supported; respect an explicit stop boundary and the repository's commit conventions, and report the delivered result and any material remaining decision.
## Handoff
Consumes: the ticket at ready from greenline status, the pinned revisions in its consumes
Produces: .greenline/work/tickets/TKT-NNN.md, status claimed then implementing then implemented with result_commit; the commits; the implementation account pinned to that result commit; evidence under .greenline/work/evidence/TKT-NNN/
Next: delivery-review reads the ticket, its account and base_commit..result_commit; at close, record-architecture-decisions evaluates whether the work surfaced a durable decision
agents/openai.yaml
harnessremoved filebaseline-copies-2026-09-11
the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected
interface:
display_name: "Implement"
short_description: "Build work from a spec or tickets"
policy:
allow_implicit_invocation: false
The timeline
Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.
2026-09-11baseline-copies-2026-09-11
the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it
SKILL.md
harnesschangedbaseline-copies-2026-09-11
greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: implement
name: "implement"
description: "Implement a piece of work based on a spec or set of tickets."
description: "Build one frontier ticket in a fresh context, or make one settled fix with no ceremony on the light path. Use for 'build TKT-NNN', 'next ticket', and small clear changes: fix, add, rename, adjust."
disable-model-invocation: true
lifecyclechangedbaseline-copies-2026-09-11
greenline prelude, to fold: one owned ticket, compact unless on the light path; commit the result, finalize the account, then request delivery-review; greenline status finds ready work
**greenline prelude: one owned ticket.** Read `.greenline/WORK.md` and `.greenline/ledger/README.md`. A settled change without a ticket gets one compact ticket with intent, scope, and falsifiable acceptance, unless it is on the light path of AGENTS.md step 2, which gets none. An existing ticket retains its global ID and evidence home. Read it and the actual revisions in its `consumes`; stale inputs must be reassessed before dependent work.
**Lifecycle integration:** the body's final review/commit pair runs in WORK.md's
order: commit the coherent implementation result, then finalize and commit its
account with that exact resultCommit before requesting independent delivery-review.
The later accounting commit is a separately pinned review input; it does not
extend the implementation range. This replaces the body's
review-before-commit ordering; its review method and test obligations stay intact.
Use `greenline status` to identify ready work. A ticket already claimed or implementing under your own claim is a resumption: read its reviews and commits since the base, then continue what remains. Review findings return to that same owner. Follow the retrieval loop in AGENTS.md before the first edit, respecting the touched roots' decisions. Guidance delivery facts come from generated receipts; add only the meaning and result evidence. Account for preparatory upkeep in this same contribution. The request's grant carries its supporting stages; a consequential unresolved decision returns to the operator with evidence.
renamechangedbaseline-copies-2026-09-11
renamed skill references and bare roster names in prose (the notation pass)
Use /tdd where possible, at pre-agreed seams.
Use tdd where possible, at pre-agreed seams.
renamechangedbaseline-copies-2026-09-11
renamed skill references and bare roster names in prose (the notation pass)
Once done, use /code-review to review the work.
Once done, use delivery-review to review the work.
lifecyclechangedbaseline-copies-2026-09-11
greenline completion, to fold: the ticket evidence contract: actual result commit, demonstrated acceptance, visible failures; the reviewer creates the review record; one bounded review round
## greenline completion: ticket evidence
Follow `.greenline/WORK.md` for claim, implementation, review, and completion. Record the actual result commit and demonstrated acceptance in the ticket, with this contribution's ledger and relied-on evidence linked. Keep a failed or unrun check visible. Quantified acceptance needs evidence covering the stated set, with any explicit exceptions accounted for; a sample cannot prove an exhaustive claim.
Commit the coherent result before independent delivery-review. The reviewer creates the review record when taking the ticket from implemented to reviewing. Keep the recorded claim as the return address for findings. Rework changes the result and reopens affected verification; a second review round waits for the operator's word. A compact ticket follows the same evidence contract as initiative work.
Evaluate consequential architectural decisions and meaningful standards changes, preserving their reasons in the established homes. The shared request owner continues the one authorized review round, its rework, and verification; the operator need not relay those stages. Complete only when the ticket's acceptance and required independent proof are supported. Respect an explicit stop boundary and repository commit conventions. Report the delivered result and any material remaining decision.
agents/openai.yaml
harnessremoved filebaseline-copies-2026-09-11
the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected
interface:
display_name: "Implement"
short_description: "Build work from a spec or tickets"
policy:
allow_implicit_invocation: false
2026-09-11pull-2026-09-11
pin advance to 3cca18b: upstream moved with no change under the vendored paths
2026-09-11fold-2026-09-11
the fold (ADR 0039, S3): the prelude and completion are gone and the ticket, the claim, the commit-then-account-then-review order, the one bounded review round and the decision harvest sit in the sentences where the builder reaches them, with the Handoff section the skills-handoff gate parses
SKILL.md
scopechangedfold-2026-09-11
one opening paragraph in the skill's voice: fires on 'build TKT-NNN', 'next ticket' and a small clear change; shaping goes to grill-with-docs, planning to to-spec and to-tickets, review to delivery-review, proof to verify-this; never reviews its own result or settles an open consequential decision
Implement the work described by the user in the spec or tickets.
This skill builds one ready ticket, or makes one settled fix on the light path. It fires on "build TKT-NNN", "next ticket", and a small clear change: fix, add, rename, adjust. An open product question is not settled here: it goes to grill-with-docs, and a plan to to-spec and to-tickets. The independent review belongs to delivery-review and the proof of acceptance to verify-this; this skill never reviews its own result, and a consequential unresolved decision returns to the operator with evidence rather than being decided during the build.
lifecyclechangedfold-2026-09-11
the work is one ready ticket from greenline status (a compact ticket for a settled change without one, none on the light path of one source file and its test with no open choice), read with the pinned revisions in its consumes, claimed with claimed_by and base_commit under an implementation account, resumed when already claimed, and preceded by the retrieval loop in AGENTS.md
Use /tdd where possible, at pre-agreed seams.
Implement the work described by the user in the spec or tickets. The work is one ticket: `greenline status` lists the ready frontier, and a settled change that has no ticket gets one compact ticket with intent, scope and falsifiable acceptance as `.greenline/WORK.md` defines it, except on the light path, where a change confined to one source file and its test, with no open choice, takes fix, checks, one commit and the reply, with no ticket, account or review. A change across files is never light. Read the ticket and the actual revisions in its `consumes`; a stale input is reassessed before dependent work. Claim it with `claimed_by` and `base_commit`, and create the implementation account as `.greenline/ledger/README.md` defines it; a ticket already claimed or implementing under your own claim is a resumption, so read its reviews and the commits since the base and continue what remains. An existing ticket keeps its global ID and evidence home. Follow the retrieval loop in AGENTS.md before the first edit, respecting the touched roots' decisions; guidance delivery facts come from generated receipts, and you add only the meaning and result evidence. Preparatory upkeep belongs to this same contribution.
renamechangedfold-2026-09-11
bare roster name in prose: /tdd is tdd; the same rename as before the fold, remeasured because the surrounding lines moved
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
Use tdd where possible, at pre-agreed seams.
locationchangedfold-2026-09-11
the checks' captured commands and outcomes live under .greenline/work/evidence/TKT-NNN/ and are referenced from the account's checks; a failed or unrun check stays visible and quantified acceptance needs evidence covering the stated set
Once done, use /code-review to review the work.
Run typechecking regularly, single test files regularly, and the full test suite once at the end. Keep each captured command and its outcome under `.greenline/work/evidence/TKT-NNN/`, referenced from the account's `checks`, and keep a failed or unrun check visible. Quantified acceptance needs evidence covering the stated set, with any explicit exceptions accounted for; a sample cannot prove an exhaustive claim.
methodchangedfold-2026-09-11
upstream reviews before committing; greenline commits the coherent result, finalizes the account, then requests one bounded delivery-review of the committed ticket (the block, step 5; the S6 QA fix the operator approved on 2026-09-11), so this hunk changes the method order
Commit your work to the current branch.
Once done, commit your work to the current branch: the coherent implementation result, with `result_commit` recorded on the ticket and the ticket at implemented. Then finalize the implementation account with that exact `resultCommit` and commit it separately; the accounting commit is a review input of its own and does not extend the implementation range.
Then request delivery-review of the committed ticket, its account and `base_commit..result_commit` through an available subagent tool, giving the reviewer the relevant contracts and retrieval access: one bounded round, part of the authorized work, not an operator relay. The reviewer writes the review record when it takes the ticket from implemented to reviewing. Findings return to this claim; rework changes the result and reopens affected checks, review and verification. The findings and any rework go to the operator with the reply, and a further round waits for the operator's word. When no delegation tool is available, record that limit in the account, leave the ticket implemented and blocked for review, and reply; the operator can open a fresh reviewing session. Before the ticket closes, evaluate whether the work surfaced a durable decision and record it with record-architecture-decisions in the established home, or state plainly that none was needed. The ticket completes only when its acceptance, the independent review and the verification are supported; respect an explicit stop boundary and the repository's commit conventions, and report the delivered result and any material remaining decision.
## Handoff
Consumes: the ticket at ready from greenline status, the pinned revisions in its consumes
Produces: .greenline/work/tickets/TKT-NNN.md, status claimed then implementing then implemented with result_commit; the commits; the implementation account pinned to that result commit; evidence under .greenline/work/evidence/TKT-NNN/
Next: delivery-review reads the ticket, its account and base_commit..result_commit; at close, record-architecture-decisions evaluates whether the work surfaced a durable decision
2026-09-11series-s7-roster-2026-09-11
The S7 series (premium Codex, the judge's owed finding): the decision trigger at close sharpened so a convention other code must follow, or a trade-off accepted beyond the acceptance, is recorded or offered even when an existing decision dictated the behaviour; the same paragraph carries the confirmed commit-then-review order.
SKILL.md
methodchangedseries-s7-roster-2026-09-11
upstream reviews before committing; greenline commits the coherent result, finalizes the account, then requests one bounded delivery-review of the committed ticket (the block, step 5; the S6 QA fix the operator approved on 2026-09-11), so this hunk changes the method order Confirmed by the operator on 2026-09-11 (method-rulings.md). The same paragraph now names the two tests of a durable decision (a convention other code must follow; a trade-off beyond the acceptance) and allows an offer, a scope sharpening from the S7 series.
Commit your work to the current branch.
Once done, commit your work to the current branch: the coherent implementation result, with `result_commit` recorded on the ticket and the ticket at implemented. Then finalize the implementation account with that exact `resultCommit` and commit it separately; the accounting commit is a review input of its own and does not extend the implementation range.
Then request delivery-review of the committed ticket, its account and `base_commit..result_commit` through an available subagent tool, giving the reviewer the relevant contracts and retrieval access: one bounded round, part of the authorized work, not an operator relay. The reviewer writes the review record when it takes the ticket from implemented to reviewing. Findings return to this claim; rework changes the result and reopens affected checks, review and verification. The findings and any rework go to the operator with the reply, and a further round waits for the operator's word. When no delegation tool is available, record that limit in the account, leave the ticket implemented and blocked for review, and reply; the operator can open a fresh reviewing session. Before the ticket closes, evaluate whether the work surfaced a durable decision: a convention other code must now follow, or a trade-off accepted beyond the ticket's acceptance, is one even when an existing decision dictated the behaviour; record it with record-architecture-decisions in the established home, or offer to, or state plainly that none was needed. The ticket completes only when its acceptance, the independent review and the verification are supported; respect an explicit stop boundary and the repository's commit conventions, and report the delivered result and any material remaining decision.
## Handoff
Consumes: the ticket at ready from greenline status, the pinned revisions in its consumes
Produces: .greenline/work/tickets/TKT-NNN.md, status claimed then implementing then implemented with result_commit; the commits; the implementation account pinned to that result commit; evidence under .greenline/work/evidence/TKT-NNN/
Next: delivery-review reads the ticket, its account and base_commit..result_commit; at close, record-architecture-decisions evaluates whether the work surfaced a durable decision
2026-09-12vocabulary-owner-2026-09-12
The workspace's person is the owner: the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12); every earlier claim on a re-measured hunk is carried forward under its own kind, with its authority where it had one.
SKILL.md
scopechangedvocabulary-owner-2026-09-12
one opening paragraph in the skill's voice: fires on 'build TKT-NNN', 'next ticket' and a small clear change; shaping goes to grill-with-docs, planning to to-spec and to-tickets, review to delivery-review, proof to verify-this; never reviews its own result or settles an open consequential decision (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
Implement the work described by the user in the spec or tickets.
This skill builds one ready ticket, or makes one settled fix on the light path. It fires on "build TKT-NNN", "next ticket", and a small clear change: fix, add, rename, adjust. An open product question is not settled here: it goes to grill-with-docs, and a plan to to-spec and to-tickets. The independent review belongs to delivery-review and the proof of acceptance to verify-this; this skill never reviews its own result, and a consequential unresolved decision returns to the owner with evidence rather than being decided during the build.
methodchangedvocabulary-owner-2026-09-12
upstream reviews before committing; greenline commits the coherent result, finalizes the account, then requests one bounded delivery-review of the committed ticket (the block, step 5; the S6 QA fix the operator approved on 2026-09-11), so this hunk changes the method order Confirmed by the operator on 2026-09-11 (method-rulings.md). The same paragraph now names the two tests of a durable decision (a convention other code must follow; a trade-off beyond the acceptance) and allows an offer, a scope sharpening from the S7 series. (carried from series-s7-roster-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
Commit your work to the current branch.
Once done, commit your work to the current branch: the coherent implementation result, with `result_commit` recorded on the ticket and the ticket at implemented. Then finalize the implementation account with that exact `resultCommit` and commit it separately; the accounting commit is a review input of its own and does not extend the implementation range.
Then request delivery-review of the committed ticket, its account and `base_commit..result_commit` through an available subagent tool, giving the reviewer the relevant contracts and retrieval access: one bounded round, part of the authorized work, not an owner relay. The reviewer writes the review record when it takes the ticket from implemented to reviewing. Findings return to this claim; rework changes the result and reopens affected checks, review and verification. The findings and any rework go to the owner with the reply, and a further round waits for the owner's word. When no delegation tool is available, record that limit in the account, leave the ticket implemented and blocked for review, and reply; the owner can open a fresh reviewing session. Before the ticket closes, evaluate whether the work surfaced a durable decision: a convention other code must now follow, or a trade-off accepted beyond the ticket's acceptance, is one even when an existing decision dictated the behaviour; record it with record-architecture-decisions in the established home, or offer to, or state plainly that none was needed. The ticket completes only when its acceptance, the independent review and the verification are supported; respect an explicit stop boundary and the repository's commit conventions, and report the delivered result and any material remaining decision.
## Handoff
Consumes: the ticket at ready from greenline status, the pinned revisions in its consumes
Produces: .greenline/work/tickets/TKT-NNN.md, status claimed then implementing then implemented with result_commit; the commits; the implementation account pinned to that result commit; evidence under .greenline/work/evidence/TKT-NNN/
Next: delivery-review reads the ticket, its account and base_commit..result_commit; at close, record-architecture-decisions evaluates whether the work surfaced a durable decision
2026-09-15roster-keepers-2026-09-15
The light-path copy omitted the failing-test condition the block states (the audit J-5, finding 8; found again by J-10); the copy now matches the keeper, corpus/runtime/agent.md. The earlier claim is carried forward.
SKILL.md
lifecyclechangedroster-keepers-2026-09-15
the work is one ready ticket from greenline status (a compact ticket for a settled change without one, none on the light path of one source file and its test with no open choice, whose failing test, if any, already names it), read with the pinned revisions in its consumes, claimed with claimed_by and base_commit; carried from fold-2026-09-11, the failing-test condition added to match the block (J-8, 2026-09-15)
Use /tdd where possible, at pre-agreed seams.
Implement the work described by the user in the spec or tickets. The work is one ticket: `greenline status` lists the ready frontier, and a settled change that has no ticket gets one compact ticket with intent, scope and falsifiable acceptance as `.greenline/WORK.md` defines it, except on the light path, where a change confined to one source file and its test, with no open choice, whose failing test, if any, already names it, takes fix, checks, one commit and the reply, with no ticket, account or review. A change across files is never light. Read the ticket and the actual revisions in its `consumes`; a stale input is reassessed before dependent work. Claim it with `claimed_by` and `base_commit`, and create the implementation account as `.greenline/ledger/README.md` defines it; a ticket already claimed or implementing under your own claim is a resumption, so read its reviews and the commits since the base and continue what remains. An existing ticket keeps its global ID and evidence home. Follow the retrieval loop in AGENTS.md before the first edit, respecting the touched roots' decisions; guidance delivery facts come from generated receipts, and you add only the meaning and result evidence. Preparatory upkeep belongs to this same contribution.
2026-09-15light-path-negative-2026-09-15
The run r15-compact-oss-codex (J-12, its judge's F1 and F2) found the light path taken with a red test that did not name the change and an unkept instruction resolved alone; the block now states the negative case in its own words and the copy follows. The earlier claim is carried forward.
SKILL.md
lifecyclechangedlight-path-negative-2026-09-15
the work is one ready ticket from greenline status (a compact ticket for a settled change without one, none on the light path of one source file and its test with no open choice, whose failing test, if any, already names it; a test red before the work starts that does not name the change makes it not light, a red test written for the change does not count, and an instruction the change cannot keep is an open choice), read with the pinned revisions in its consumes, claimed with claimed_by and base_commit; carried from roster-keepers-2026-09-15 (J-13, 2026-09-15)
Use /tdd where possible, at pre-agreed seams.
Implement the work described by the user in the spec or tickets. The work is one ticket: `greenline status` lists the ready frontier, and a settled change that has no ticket gets one compact ticket with intent, scope and falsifiable acceptance as `.greenline/WORK.md` defines it, except on the light path, where a change confined to one source file and its test, with no open choice, whose failing test, if any, already names it, takes fix, checks, one commit and the reply, with no ticket, account or review; a test red before the work starts that does not name the change makes it not light, a red test written for the change does not count, and an instruction the change cannot keep is an open choice. A change across files is never light. Read the ticket and the actual revisions in its `consumes`; a stale input is reassessed before dependent work. Claim it with `claimed_by` and `base_commit`, and create the implementation account as `.greenline/ledger/README.md` defines it; a ticket already claimed or implementing under your own claim is a resumption, so read its reviews and the commits since the base and continue what remains. An existing ticket keeps its global ID and evidence home. Follow the retrieval loop in AGENTS.md before the first edit, respecting the touched roots' decisions; guidance delivery facts come from generated receipts, and you add only the meaning and result evidence. Preparatory upkeep belongs to this same contribution.