A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I1401

The identity of a projected record is what the record carries, not what its title says

Where it stands

devtask.issue

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: work-graph-github
Milestone status: VERIFY
Wave: 0
Waiting on: none
Holds back: I1402 I1403 I1405
Behind it in all: 6
Evidence: 2 of 2

Moves

plan.transition

What it is

Objective: Make the adapter find a remote record by an identity the record itself carries, so that a person may rename an issue on GitHub without the projection losing it or creating a second one, and make reconciliation provable without a network.
Why: Matching on a title is the one mistake a projection may not make. `remote_issue_number()` matched an `I0001 — ` prefix in the remote title, and every other question about a remote record was answered by the same prefix scan. Rename an issue on GitHub and the adapter reports it missing; run --apply and it creates a duplicate for a canonical record that already exists. The remedy must not be to write the GitHub number into the canonical file, because the adapter's own contract is that nothing here ever writes a GitHub value back into a canonical record.
Now: The adapter resolved five separate questions by scanning the remote title for a canonical prefix, and recovered the number of a freshly created issue by searching GitHub for that title again. The generated region carried the hash of the record it came from and nothing that said which record that was.
Wanted: The generated region carries `` beside its hash, so identity travels with the record and a splice rewrites it. Resolution is by that marker; a title matches once, for an issue projected before the marker existed, and that adoption is reported as its own state rather than passing as a projection that is current. A created issue takes its number from the creation itself. The remote can be a file, so which record is which is provable offline.
Done when: unknown: the record declares no `completion`
Risk: The 19 issues projected before the marker existed must be adopted, never re-created; the adoption path is the acceptance criterion that guards it.

Acceptance

A record is resolved by the identity it carries, and a renamed title neither loses it nor duplicates it
An issue carrying no identity marker is adopted by its title once, reported as an adoption, and given a marker by --apply
A title that merely looks canonical never captures a record that carries a different identity
A created issue takes its number from the creation, with no title search anywhere in the adapter
Reconciliation is provable against a fixture remote with no network and no token, and a fixture is refused for --apply

Validation: bash test/run.sh 45_github_projectionscripts/github-sync --planscripts/github-sync --check
Evidence required: identity_stableoffline_provable
Evidence present: identity_stableoffline_provable

Scope

Touches: scripts/github-synctest/cases/45_github_projection.sh
Not: Writing a GitHub number into a canonical recordAny change to what the projection renders
Depends on: none
Priority: p0
Profile: implementation
Parallel safe: false
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-09-09
Updated: 2026-09-09T17:10:28Z
Started: 2026-09-09T17:10:06Z
Verified: 2026-09-09T17:10:21Z
Completed: 2026-09-09T17:10:28Z

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.