I1516

What it is

Objective

Make the body scripts/github-sync posts to an issue the same text it prints for that issue, by composing it once, so that a body the adapter wrote is a body the adapter recognises as its own.

Why

The adapter composed the generated region twice — once for --render and once for the splice that updates an issue that already exists — and the two compositions drifted. record_marker() prints without a trailing newline; --render wrapped it in printf '%s\\n' and the splice did not, so the first line of the record was glued to the marker in every body the splice posted. region_intact() drops the marker line before hashing the region back, and that prefix match took the glued first line with it, so such a region never hashed to what its own marker claimed. Every issue written through the splice was then classified `edited` — a person's hand-edit, never to be overwritten — and --force could not repair one, because it rewrote it exactly the same way. This is measured, not hypothetical: 19 of the 215 managed issues on GitHub carry a marker line with body text appended, and they are exactly the 19 findings that keep the github-projection gate red.

Now

19 managed issues carry a concatenated marker line; scripts/ci/github-check exits 10 on them; the structure job fails on every branch that reaches it. test/cases/45 exercises only the --render composition, so the splice composition has never been tested at all. Refreshed onto master 2026-09-30 from PR #554: master still carries both compositions.

Wanted

One function composes the region's content, and both the rendering and the splice call it. Case 45 refuses a second composition and a caller that writes the marker without ending its line; case 602 drives --apply against a stubbed gh and reads the posted body back as insync. The 19 remote bodies are rewritten by --apply --force and the gate goes green.

Done when

unknown: the record declares no `completion`

Risk

Low. The change removes a duplicate definition; the rendering it keeps is the one every other surface already prints.

Acceptance

Scope

Touches

scripts/github-synctest/cases/45_github_projection.shtest/cases/602_a_spliced_body_is_recognised_as_its_own.sh

Not

The remote rewrite itself, which is an operation and not a change to the repository.The drift baseline, which shrinks on its own once the bodies are correct.

Depends on

none

Priority

p0

Profile

implementation

Parallel safe

true

Owner

unknown: the record declares no `owner`

The work so far

Synchronisation

Adapter

scripts/github-sync

Repository

unknown: the derived plan's header carries no repository

External issue

unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

State there

unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.