chore(memory): promote strong-fit contacts drafts for review

[Hareet]

Promotes 44 strong-fit contacts drafts from agent-memory/_pending/ into agent-memory/domains/contacts/issues/ for squad content review.

Categories: feature (27), bug (10), improvement (7)
Themes: cht-datasource person/place create/update/get, contact-summary fetch performance, contact forms/attachments, lineage handling.

All 44 carry domainFit: strong + a ## Domain Rationale section. 7 weak-fit drafts deferred for later.

• Base: seeding-claude-cli-v2 (feat(#108): seeding pipeline - CLI provider, domain-rationale, infrastructure domain, concurrency #119) — retarget to main after the schema lands.
• validate-schema: passing, 0 failures.
• Review for content (domain fit + distillation accuracy), not code.

[sugat009]

Requesting changes, though to be clear the fix is upstream and not something to patch by hand here. This seeder faithfully promotes what the distillation pipeline generated, so nothing is wrong with the promotion itself. The problem is in the drafts the pipeline produced, and I verified it against the live medic/cht-core API for every draft in this PR.

The defect: issueNumber / issueUrl name the merge PR, not the resolved issue

One precise note up front, because the intuitive version of this is not what is happening: issueNumber and issueUrl always agree with each other (the URL is literally /issues/<issueNumber>). The bug is that in 31 of 44 drafts here, that shared number is a pull request, so /issues/N silently redirects to /pull/N. The real resolved issue survives only in the PR-title slug. For example:

• 10043-feat10036-add-personqualifier... stores issueNumber: 10043 / issueUrl: .../issues/10043, but 10043 is the merge PR ("feat(#10036): add PersonQualifier and related functions"). The real issue is #10036 (closed): "To have API that can create people".
• 10057-feat10038-add-placequalifier... stores issueNumber: 10057 / issueUrl: .../issues/10057, but 10057 is the merge PR ("feat(#10038): add PlaceQualifier and related methods"). The real issue is #10038 (closed): "To have API that can create places".

This is the same scraper behaviour flagged on #121, and it is pipeline-wide: across the four clean seeders, 60 of 107 drafts are affected.

Duplicates in this PR. Because each draft is keyed by its PR, some resolved issues appear more than once:

• Several issues map to many drafts: #10038 (5 drafts), #10036 (3), #10037 (2), #8985 (2), #9241 (2).
• Three are also in the authentication seeder #131 (cross-domain): #9835, #9065, #6543.

Also. One draft (9311) is a worse variant: it stores issueNumber: 9241, which is neither its own PR nor the issue its PR title references, but a third, unrelated issue.

Why request-changes rather than merge-and-fix-later

This corpus is the agent's memory of resolved issues (consumed by the Context Analysis Agent, see #135). A reference that resolves to a PR instead of the issue is simply wrong data, and it specifically defeats #135's planned de-duplication by issue id, since the "id" ends up being the PR id. Regenerating the drafts after the upstream fix will rewrite most of these files anyway, so merging now would churn the corpus twice.

Suggested fix (at the source, not file by file)

1. Fix the distiller/scraper to take the resolved issue from the type(#N): PR title (the filename slug already extracts it correctly), and keep the PR number in source_pr where it belongs.
2. Regenerate and re-promote this domain's drafts.
3. Add de-duplication by real issue id (also a #135 acceptance item).

Open to discussing the approach. Once the drafts carry the real issue references, this should be a quick re-review.

[Hareet]

@sugat009
Rebased onto main and addressed the review: identity keys relinked via #129's tool (31 files, all 43 PR→issue mappings re-verified against the cht-core API); duplicate clusters collapsed to one memory per issue with source_prs[] (schema gains the optional field, identical to #138's definition); cross-domain dupes resolved — #9835/#9065 stay here, #6543 moves to the authentication seeder. One correction from verification: 9311 was actually keyed correctly — PR #9311's body explicitly closes #9241 (the people REST-endpoint ticket); it's now folded into the #9241 canonical alongside #9295.

[sugat009]

Content re-review. Identity/dedup/schema clean; the 7 modified drafts are benign except 9915 (a Testing reword that silently drops a "Reviewer verified" attribution — minor). Remaining:

• issue (accuracy): 9281 inverts the getAll AsyncGenerator semantics (inline).
• issue (domain): four drafts (10043/10057/9266/9281) are pure cht-datasource Person/Place-qualifier extension → agreed data-access domain (inline on 10043). NB this is also where the 10022/10246 report-datasource content from #122 landed (in 9835) — all datasource extension currently sitting in contacts.
• nitpick (leakage): 9007 Domain Rationale ("Per the infrastructure pitfall"); strip.

Cross-cutting (whole promote batch, not blocking this PR alone): filenames still encode the PR number while frontmatter is issue-keyed, and two draft schemas coexist (machine-distilled vs hand-authored) — worth a cleanup pass. Full detail + re-runnable Verify commands are in my consolidated review notes.

The largest cross-cutting item, moving the cht-datasource library-extension drafts to a first-class data-access domain + a weighted secondaryDomains[] field, is in the detailed data-access proposal comment on #122.

[sugat009]

issue (accuracy): the draft says getAll yields pages (arrays) and shows a nested-loop snippet, but the AsyncGenerator yields individual Person docs one-by-one (PR #9281: for (const doc of docs.data) { yield doc }; the spec asserts "yields document one by one"). As written it would teach an agent the wrong iteration. Correct to e.g. for await (const person of Person.v1.getAll(ctx)(qualifier)) { … }.

[sugat009]

issue (domain): 10043 (PersonQualifier), 10057 (PlaceQualifier), 9266/9281 (getPeople) are pure cht-datasource library extension (anchor PRs touch only shared-libs/cht-datasource) — the Person/Place qualifiers the agreed data-access domain (#11174 hierarchy) is organized around. They belong in data-access with secondaryDomains: [contacts]. See the detailed data-access proposal comment on #122.

[Hareet]

Request for re-review

All four of your items are fixed, each re-derived from the PRs' own diffs before
being touched rather than taken on your word — all four held up. Then the same
sweep #123 got turned up a great deal more outside your list than in it,
including one draft whose entire narrative is backwards and one that documents a
feature which is not on master at all.

Two things to know before the findings. The PR body's "44 drafts" is stale —
the directory holds 37, and this PR's own diff is 34 of them plus
agent-memory/schema.json (27 added, 7 modified). 10074, 8034 and 8074 are
already on main and untouched by #132; I swept them anyway and committed the
fixes separately so you can drop that commit without disturbing the promotion.

And the gate as we have been running it cannot see cross-domain duplicates —
which is the one class you filed first. Details below; it is the most important
thing in this reply.

---

The gate has been running a weaker dedup check than the docs claim

verify-drafts computes duplicate-issue "across the WHOLE corpus, including
already-landed drafts". It does — but only within the tree it is pointed at, and
the documented pre-push command points it at one domain:

# what the runbook says, and what we have been running:
npm run verify-drafts -- --dir <worktree>/agent-memory/domains/contacts
#   37 drafts checked, 0 blocking

# the same bytes, scanned corpus-wide:
npm run verify-drafts -- --dir <worktree>/agent-memory
#   [duplicate-issue] contacts/issues/8034-replicate-primary-contacts-max-depth.md
#       medic/cht-core#8034 is also claimed by
#       9593-feat8034-replicate-primary-contacts-at-max-depth.md

const dir = path.resolve(REPO_ROOT, opts.dir ?? 'agent-memory') is the whole
story: a narrowed --dir silently downgrades a corpus check to a
within-directory one and still reports "0 blocking". Round 2's "identity/dedup
clean" was produced by that narrowed scan, so it is not evidence about
cross-seeder duplicates either way.

I re-checked your three by hand and all three are genuinely resolved — each
issue now has exactly one claimant:

for iss in 9835 9065 6543; do git grep -l "issueNumber: $iss$" \
  memory/promote-contacts memory/promote-authentication main -- 'agent-memory/domains/*'; done
#   #9835 -> contacts/9835 only        #9065 -> contacts/9090 only
#   #6543 -> authentication/9126 only

The 8034/9593 collision is not introduced by this PR — both files are
already on main, and 8034 is not in #132's diff. It is a landed-corpus defect
and collapsing two drafts across domains is your call, not a contacts one, so I
have not touched it. But it would have shipped unseen, and it will keep shipping
unseen on every domain until either the runbook points --dir at
agent-memory/ or the script warns when the scan root is narrower than the
corpus. I would take the warning.

---

Your four items

9281 — the getAll inversion, confirmed and fixed. The generator yields
documents, not pages:

git -C $CORE show refs/verify/pr9281:shared-libs/cht-datasource/src/libs/data-context.ts
#   export const getDocumentStream = async function* <S, T>(...): AsyncGenerator<T, void>
#     for (const doc of docs.data) { yield doc; }
git -C $CORE show refs/verify/pr9281:.../test/libs/data-context.spec.ts | grep -n 'it('
#   131: it('yields document one by one'

Rewritten to the flat for await (const person of Person.v1.getAll(ctx)(q))
shape, with the facade test's own assertion cited — it drains the generator and
deep-equals the result against the flat array of people, not a list of pages.

Two things surfaced while verifying that the draft now records. #9281
squash-merged into the 9193-api-endpoints-for-getting-contacts-by-type feature
branch (bf8a77da, not an ancestor of master) and reached master only via
#9311 (34dd0303c) — which is why its source_sha will not resolve in a plain
clone. And the helper was renamed before landing: at #9311's squash it is
already getPagedGenerator in libs/core.ts, getDocumentStream is gone, and
the signature is already AsyncGenerator<Person, null>. That is time-scoped in
the draft, not silently corrected to master's shape. The same PR also replaced
getPage's numeric skip with a string cursor and moved it ahead of limit
(- return fn(personType, limit, skip) → + return fn(personType, cursor, limit)).

10043/10057/9266/9281 plus 9835 — data-access, deferred with an
explicit disclosure on each. Your "extend vs use" rule is satisfied exactly for
the four you named: each of their anchor PRs touches shared-libs/cht-datasource
and nothing else.

for pr in 10043 10057 9266 9281; do
  sha=$(git -C $CORE log --all --fixed-strings --grep="(#$pr)" --format=%H | head -1)
  echo "#$pr:"; git -C $CORE diff-tree --no-commit-id --name-only -r "$sha" \
    | sed 's|/[^/]*$||' | sort -u | sed 's/^/   /'
done
#   every line under shared-libs/cht-datasource — no api/, no webapp/

9835 is the fifth and I am treating it as a candidate rather than a proven
extender: it is hand-authored, spans five source_prs, and two of those
(#10083's api controllers) do reach outside the library. It is where the
10022/10246 report-datasource content from #122 landed, which is your own
reason for wanting it in data-access — but the mechanical rule does not settle
it the way it settles the other four.

Deferred on your own sequencing — "one coordinated schema/taxonomy PR … Not
blocking any single PR" — and the #123 precedent. Two concrete reasons beyond
precedent: data-access is not a valid domain today (the CHTDomain enum
holds nine values, none of them it) and PR #152 already adds it and is open,
so re-keying here means two open PRs racing to add the same enum value; and
until #135 lands union selection, a re-keyed draft drops out of contacts
retrieval entirely. Each of the five now says that in its own text rather than
leaving a reader to wonder why a pure datasource draft sits in contacts. Say the
word and I will move all five — it is a small change now that the reasons are
written down.

9007 — leakage stripped. "Per the infrastructure pitfall" is gone. While
verifying I also pinned the vague page_size prose to the real constant
(- private readonly PAGE_SIZE = 50; / + ... = 25;) and dropped "verified
with a manual quick test" — PR #9007's body has an entirely unchecked review
checklist and mentions no manual testing.

9915 — the dropped attribution: I justified the removal rather than restore
it, because restoring it would re-assert something the diff contradicts. The
original read "Reviewer verified the correct workflow (xlsx edit → xml
regeneration) was followed". That workflow was not followed for 12 of the 29
changed XMLs:

git -C $CORE diff-tree --no-commit-id --name-status -r 41362a25 | wc -l     # 50, all M
#   29 .xml / 21 .xlsx; of the 29, 17 have a same-named .xlsx changed beside them
#   the other 12 are the place create/edit forms, expanded from 4 shared
#   PLACE_TYPE-*.xlsx templates and edited directly

Re-adding "the correct workflow was followed" would contradict the draft's own
Solution section, which now describes both paths. The Testing section instead
states what is checkable from the diff. The counts were wrong too and are fixed
(default/app 10→11, covid-19/contact 6→8).

---

The 10432 loose end from #123 — closed, nothing was dropped

Your #122 comment says 10432 "relocated to contacts". It is here. It is filed
under the issue it resolves, not the PR, which is why grepping for a
10432-* file finds nothing:

ls agent-memory/domains/contacts/issues/ | grep 10344
#   10344-targets-by-contact-id-cht-datasource.md      (source_prs: medic/cht-core#10432)

What it did need is scoping, because PR #10432 never merged and the draft
asserted all of it as shipped behaviour:

git -C $CORE merge-base --is-ancestor refs/verify/pr10432 origin/master; echo $?  # 1
git -C $CORE grep -c byContactUuids origin/master                                 # no output
git -C $CORE grep -lc byContactUuids refs/verify/pr10432                          # 12 files

It now opens with a banner saying so and carries stale: true.

Worth flagging that my first version of that banner was wrong in two ways, and
the corrections are in the same commit: it said no commit in cht-core references
the PR (one does — db9694ef0 — it is simply not reachable from master), and it
listed bindGenerator() among symbols existing "only on that open PR's branch".
bindGenerator is on master in six files, added by epic #10423 (622c62542),
and master's target-aggregates.service.ts:35 binds Target.v1.getAll — so the
summary's flat "None of this API exists on master" was also too strong. Same
failure mode as everything else here, committed by the person fixing it.

---

What the sweep found on drafts you did not name

9230 is inverted end to end — the worst single draft in the corpus. It said
leftover action-bar logic prevented editing a home place and the fix restored
the ability. The real bug is the exact opposite:

git -C $CORE show 9f900220 -- webapp/src/ts/modules/contacts/contacts-content.component.ts
#  - canEdit: ... this.userSettings?.facility_id !== this.selectedContact?.doc?._id,
#  + canEdit: ... !this.userSettings?.facility_id?.includes(...doc?._id),

#9229: "Old action bar should prevent users with multiple facilities
assigned from editing the homeplace" — "See the edit button is enabled … It
should be disabled."

Once facility_id became an array, ['x'] !== 'x' is always true, so canEdit
was always true and the button was wrongly enabled. Title, summary, Problem,
Root Cause, Solution, Design Choices, Domain Rationale and the tags field all
carried the inversion; all were rewritten together. Also time-scoped — the action
bar and this whole block were removed from master by #9361 — so stale: true.

8684 documents a feature that is not on master at all, and claimed
stale: false.

git -C $CORE merge-base --is-ancestor 59a1dbd2 origin/master; echo $?   # 1
git -C $CORE branch -a --contains 59a1dbd2   # 4.4.1-FR-barcode, 4-4-cares, ...
for s in search_by_barcode BarcodeDetector can_use_barcode_scanner isDesktopUserAgent; do
  git -C $CORE grep -l $s origin/master | wc -l; done                   # 0 0 0 0

PR #8684 merged into the 4.4.1-FR-barcode release branch, never into
master, and issue #6669 is still open. Every path in its Related Files does exist
on master — with none of this content — so an agent grepping them finds nothing
and concludes the draft is fabricated. Now stale: true with the landing
recorded and a scope note above Related Files. Two more on the same draft: it
credited itself with browser-detector.service.ts (M in its own diff; created
by #7568 in 2022, this PR adds one method), and misquoted its own telemetry
literal — barcode_no_detected where the code says barcode_not_detected.

8984 had the 50-report cap backwards. The draft said the summary saw "only
the first 50 reports". search.js slices the tail of the date-sorted rows, so
it keeps the 50 most recent and drops the oldest — which is why issue #8815
is titled "Only last 50 reports for contact are provided" and reproduces by
submitting 50 reports after the pregnancy registration. Corrected in all four
places. Also: search.service.ts was in Related Files but is absent from the
PR's diff, and the same PR adds a separate DISPLAY_LIMIT = 50 render cap that
the draft never mentioned — the opposite direction from its own headline.

9601 and 9625 transcribe a PR description rather than its merged code.
9601 named is_canonical, a duplicate_info section and
context.duplicate_check; none of the three exists at the merge commit or on
master (the real shapes are an [duplicate-contacts] content-projection slot and
a top-level duplicate_check on the form doc). 9625 claimed freetext
search for person and place; the PR adds getUuidsPage/getUuids to contact and
report only, and creates two controllers rather than adding endpoints to four.

Five drafts credited themselves with another PR's work — your #10324
telemetryKey class. 9295 called five files new that #9090 created and that
are M in its own diff; 9368 claimed /api/v1/person when its only added
route is /api/v1/place and person was already in its parent tree; 9090 tagged
four files it created as #9176's; 9177 put getByUuid in place.ts when it
lives in index.ts; 10141 claimed a public export that #10157 added. Several
non-existent namespace members went with them (Person.v1.getPageByType,
Place.v1.getByType, Person.V1) — all are getDatasource() facade names, not
v1 namespace exports, and the drafts now distinguish the two.

10074, 8034, 8074 (the three landed drafts) each had a real defect:
every path 10074 names was deleted from master by #10187 a month after its own
PR merged, with no scoping; 8034's "most permissive wins across roles"
contradicted its own Design Choices and the PR's own test name; 8074's Solution
item 5 contradicted item 4.

Nine further contradictions surfaced only on the re-read after a fix —
9230's Domain Rationale, 8995's YAML title, 9295's Design Choices and
Testing, 9368's Related Issues and Domain Rationale, 9090's Related Issues,
9625's summary and Domain Rationale, 10141's concepts. That remains the
highest-yield class and it is generated by the act of fixing.

9264, 9390 and 10713 came back clean and are untouched apart from 9390's
Related Issues labelling.

---

What twelve rounds of the gate found after the hand sweep

The section above is what reading the drafts against the diffs produced. The gate
then found two dozen more on bytes I had already called clean, across twelve
rounds. Worth reporting because the distribution is the argument for the pass
count, not the total.

Nine of the nineteen were mine — introduced by the commits that fixed your
items and the swept siblings. Six are one shape: corrected the mechanism in the
detailed section, left the summary asserting the tidier version. 9281's
summary still called the pre-PR API cursor-paginated after I documented that this
PR replaced skip with cursor. 9915's Code Patterns still said "always
regenerate" after I documented the 12 hand-edited XMLs. 9394's summary credited
CHTDatasourceService with a function the same commit described as an empty stub.

Three more classes worth naming:

• Prose invents a qualified name for something real. 9394's
  targetAggregateService.getCurrentTargetDoc, 9177's get-person, 8995's
  contactViewModelGenerator — none exists; each names a real thing with an
  invented receiver or a hyphenated paraphrase. All three came from my edits.
• "Only X existed" enumerations of a prior state, wrong. 9177, 9835 and
  8074 in two consecutive rounds. Structural rather than careless: those
  sentences exist to motivate the change, so whatever the change did not touch
  drops out of the list. 9835's was the worst — it attributed duplicated
  validation to the very PR that centralised it (A input.ts in #10083's diff).
• Editing correct-but-unreadable prose is not free. 9264 was flagged as a
  readability problem; I rewrote it and attached the reported clinic case to
  the new-style branch. getTypeId is
  doc.type === 'contact' ? doc.contact_type : doc.type, so a legacy clinic
  doc takes the other branch — which the draft's own Root Cause already said.
  I made a true draft false, and it took two further passes to notice. Your
  "if a checker misreads it, a person will too" is right; it does not license
  editing without re-deriving the mechanism first, which is the step I skipped.

Round 7 is the single best argument for not stopping early. ground-claims
had been clean for nine consecutive passes over three commits; pass 3 of round 7
then produced two fabricated symbols on 9177. A three-pass bar taken at round 4
would have shipped them.

---

Five tooling defects this corpus exposed, all fixed with tests

A cluster draft has more than one anchor, and only the first was used.
source_prs[] lists every PR a collapsed or hand-authored draft covers, but
anchorFor takes the first entry as canonical. file-touched already consulted
the siblings; symbol, symbol-in-file and path-exists did not. 9835 lists
five source_prs, resolved to #10022 (the earliest), and returned 12
ungrounded claims — every one of them false:

git -C $CORE grep -c 'minifyDoc\|assertSameParentLineage\|getUpdatedContact' \
  origin/master -- shared-libs/cht-datasource/src/local/libs/lineage.ts   # 3
git -C $CORE grep -c assertPermissions origin/master -- api/src/controllers/person.js  # 4

Every symbol is real, on master, in exactly the file the draft names — they
simply arrived in #10081/#10083/#10222/#10246. Tree-scoped claims now retry at
each sibling anchor and say which one settled them. A single-PR draft has no
siblings, so no verdict there can change; that is a test.

Paths in this repo were adjudicated against cht-core. The data-access
banners cite agent-memory/schema.json; cht-core has no agent-memory/ tree, so
a file that plainly exists came back ungrounded on four drafts. Now
unverifiable — not our tree to settle.

A sentence that scopes itself to before the change was judged after it.
FORWARD_SCOPED rescues "on master" claims by re-checking the current tree;
there was no mirror for the past, and the Problem/Root-Cause parent retry only
fires when extraction tags a claim pre-fix, which it often does not. 9394
said "before this PR contacts.effects.ts called getCurrentTargetDoc()":

git -C $CORE grep -c getCurrentTargetDoc bbe5dedd5  -- webapp/src/ts/   # 0
git -C $CORE grep -n getCurrentTargetDoc bbe5dedd5^ -- webapp/src/ts/
#   effects/contacts.effects.ts:182:      .getCurrentTargetDoc(this.selectedContact)

Real at the parent, deleted by the PR — a true sentence reported as fabricated.
An explicit "before this PR" / "used to" / "previously" now re-checks the parent.

check-coherence still counted a pair the model had withdrawn. The existing
screen wants a negation beside the noun ("These do not conflict"). 10804's
rationale read "a minor framing difference rather than a factual conflict" —
same withdrawal, different grammar, so it was filed and I was sent to adjudicate
something already cleared. That is the exact defect the screen was added for, in
its other form.

All four on memory/draft-verification with tests; npm test 1214 passing,
tsc --noEmit and eslint . clean. eslint . needed its own commit to be
green at all: outputs/ is gitignored but was not eslint-ignored, so a stray
.ts left there by an earlier investigation fails the gate for everyone.

The enumerate-claims status inference held up on a new corpus. It inferred
10 statuses across contacts, all modified, and all 10 match the PRs' real
--name-status. 0 false positives. The tuning generalised off
tasks-and-targets; I found nothing to tighten.

---

Gate

Verified bytes: memory/promote-contacts @ 2be6148, clean tree.

tier	result	passes
validate-schema	91 passed / 0 failed	deterministic
verify-drafts (offline)	0 blocking, 1 warning	deterministic
verify-drafts --online	0 blocking, 1 warning, 0 unverified, rc=0	deterministic
ground-claims	0 ungrounded, ~717 grounded, 33 unverifiable, 0 anchor-unusable, 0 unmatched-snippet	3 consecutive clean
check-coherence	0 contradictions	3 consecutive clean

Both LLM tiers clean three times each on the same frozen commit, and all six
logs carry zero truncation markers — every pass really did cover all 37 drafts,
which is not something I could say of the first coherence run.

That took 36 ground passes and 39 coherence passes across 12 rounds, because
each round's fixes changed the bytes and restarted the count. The per-round yield:

round	ground	coherence
1 (pre-fix)	38 ungrounded	—
2	3, 4, 4	6, 5, 7
3	1, 1, 1	2, 2
4	0, 0, 0	0, 1, 0
5	0, 0, 0	0, 0, 1 → tooling
7	0, 0, 2	0, 1, 0
8–12	mostly 0	one single-pass hit per round
13	0, 0, 0	0, 0, 0

Round 7 is the one to look at. Ground had been clean for nine consecutive
passes across three commits, then pass 3 turned up two fabricated symbols. A
three-pass bar would have passed that corpus at round 4. Round 12's coherence
finding (8034's two views) appeared in one pass of three.

The 33 unverifiable are not a pass, and they are concentrated. Twenty-nine
of them are on the three drafts with no anchor metadata at all — 10074 (13),
8034 (9), 8074 (7) — which are also the three already on main and outside
this PR's diff. The remaining four are the agent-memory/schema.json references
in the data-access banners, which the probe now declines to judge because
cht-core has no such tree. Nothing in the 34 drafts this PR actually changes is
sitting on an unresolved anchor.

The single remaining warning is uniform-domain-fit, which is structural — see
the disclosure list.

Worth putting in the runbook: authenticate gh before running --online.
Anonymous, the online tier gets GitHub's 60 requests/hour and a 37-draft domain
exhausts it, so runs come back with unverified counts that look like content
problems and rc=3. With a token it is 5,000/hour — the same scan returns
0 unverified, rc=0 in one go. No code change is needed: gh-classify already
tries gh api first and only falls back to anonymous curl, so exporting
GH_TOKEN is enough. My first three online runs were all degraded by this and I
initially mis-read it as the tier being unavailable on a host without gh.

One caveat about reading these logs. An early coherence run reported
"37 drafts" while 17 of them carried coherence check failed: You've hit your weekly limit — never actually checked. The summary line looks identical to a
clean sweep. Every pass counted above was checked for that marker and none has
one, but the summary line alone will not tell you.

The sequence below is the point, not the final number:

• verify-drafts --online went 3 blocking + 18 warnings → 1 blocking + 2
  warnings → 0 blocking, and the middle step is the interesting one: the
  remaining blocker was one I had just written. Replacing 9177's useless "Related code
  change" with "created src/place.ts with the Place/PlaceWithLineage
  interfaces" is true — but it describes a side effect of #9176 rather than its
  subject, and tripped the same title-matching rule that had produced the 9390
  false positive one commit earlier. I had written up that blind spot and then
  walked into it. Fixing a draft is how you generate the next finding, on the
  tooling as much as the prose.

• The very first ground-claims pass reported 38 ungrounded across 13
  drafts. Adjudicating them by hand turned 16 into tooling defects (12 on 9835,
  4 agent-memory/ paths) and confirmed the rest.

• Pass 1 on the already hand-cleaned, committed corpus still found 2
  ungrounded and 5 contradictions. Five of those seven were content fixes a
  human pass had missed — including 10897 contradicting itself three ways, all
  three created by my own earlier fix to its Problem section. The other two were
  fresh tooling defects (below). That is precisely the argument for a pass count
  above one, and it is the argument I cannot finish making here.

• Four of the readers' independent findings were corroborated by the gate on
  the same bytes — 9601's duplicate_info/is_canonical, 9625's
  person/place search, 10777's role="button", and 9394's targetDocs. Two
  methods agreeing is the strongest signal available here.

• verify-drafts --online could not run at all until I checked why: it shells
  out through gh-classify, which tries curl first and gh second. There is
  no gh on this machine, and the first thing I assumed was that the online tier
  was simply unavailable. It is not — it works on curl alone.

A blind spot you should know about, because it cost a real edit. The
related-ref-gloss-mismatch rule compares a gloss against the referenced item's
title. 9390 glossed #9311 as "the original PR that added get-persons-by-type
support and introduced the inconsistent personType parameter". That is
correct — it is what issue #9389's own body says — but it shares almost no
vocabulary with #9311's title, so the rule fired blocking. I rewrote the gloss to
quote the real subject and keep the accurate substance, which is the right
outcome for a reader, but the finding itself was a false positive. Worth knowing
before someone deletes a true gloss to make a gate go green.

---

What I disclosed rather than fixed

• Convergence itself. One ground-claims pass and one partial
  check-coherence pass, not three of each, blocked on the weekly subscription
  limit. Everything below this line is a judgement made against a corpus that has
  had one machine pass, and pass 1 on frozen bytes found five real content
  defects — so I would expect a further pass to find something, not nothing.

• The data-access cluster — deferred, per your own sequencing, now with the
  reasons written into all five drafts. Reversible in one commit.

• 8034/9593 cross-domain duplicate — a landed-corpus decision, and the
  two drafts sit in different domains. Not a contacts fix.

• stale-as-written drift on 8684, 9230, 9426, 10777, 10804,
  10074, 8034 — time-scoped and disclosed, never rewritten to master's
  shape.

• 10344 kept rather than deleted: it records the design reasoning behind an
  open proposal, and now says so in its first paragraph.

• The two coexisting draft schemas — untouched, as you asked. One consequence
  worth naming: uniform-domain-fit reports "all 27 drafts self-report
  domainFit: strong", not 37, because the 10 hand-authored drafts have no
  domainFit at all. The warning is real but it is silently sampling 73% of the
  corpus, and the same holes mean roughly a third of these drafts anchor on a
  bare source_prs list — weaker evidence than the 25 fully-anchored drafts on
  chore(memory): promote strong-fit tasks-and-targets drafts from memory-pipeline for review #123, and the direct cause of the 9835 false-positive cluster above.

• Filenames still encode the PR number. Not blocking, per your note — but
  9230's filename now reads
  9230-fix9229-old-action-bar-prevents-editing-home-places.md against a draft
  that correctly says the opposite. The slug comes from the PR title, which was
  itself ambiguous. Flagging it because a filename is what an agent greps first.

One correction to the brief I was working from: the hand-authored set is 10
drafts, not 11 — 10897 carries source_pr, source_sha, domainFit and
confidence and is machine-distilled. 37 − 27 = 10 falls straight out of the
uniform-domain-fit count.

---

Commits

memory/promote-contacts (2be6148), 18 commits grouped by cause so any
group can be dropped on its own:

commits	what
9c53874	your four review items, each re-derived first
dc0aef7	10344 scoped to the open proposal — the 10432 loose end
ca418f6	the 23 swept drafts you did not name
55dbd0a	10074/8034/8074 — landed, outside this PR's diff
c09d099, 8991edb	Related Issues refs, glosses, timestamps
2568313 … 2be6148 (12)	one per gate round, each naming what it found and which side the diff supported

memory/draft-verification (8df2b78):

commit	what
e7d40b7	a cluster draft has more than one anchor (+ agent-memory/ paths)
4e8c0c9	keep gitignored run artifacts out of eslint .
101613b	judge a "before this PR" sentence at the parent (+ downgrade withdrawals)
6fa6949	docs: authenticate gh before running the online tier
8df2b78	a pair withdrawn as "not exclusive" is still withdrawn

npm test 1217 passing, tsc --noEmit and eslint . clean.
agent-memory/_skipped.ndjson reverted, not committed.

[sugat009]

Round 3. All five of my round-2 items are resolved, several beyond what I asked: 9281 is now precise and master-scoped, 9915 was re-derived instead of patched and its new numbers verify exactly (PR 9924 is 50 files, 29 xml + 21 xlsx, zero adds or deletes), and the out-of-diff sweep in 55dbd0a is legitimate corpus repair whose 10074 deleted-migrations claim checks out (#10187, zero person migrations on master).

Requesting changes on five items, each verified with the full protocol (head quote, anchor, master, and the commit history between them, so drift and error are distinguished) and each carrying a suggested rewording. Three are blocking: the 10057 input.ts centralization claim is false at every point in history (the file does not exist at this draft's anchor, the helpers were per-module at #10124, and master's input.ts is types-only), the 9835 permission enumeration is wrong for five of six write endpoints, and 8684's "all listed files still exist on master" fails for config/standard/app_settings.json.

Two notes, neither blocking: the 55dbd0a "drop this commit" separability claim is stale now that later commits re-touched 8034/8074, worth a one-line follow-up in the PR description; and the same epic-branch template suggestion as on #122 applies to 10344's banner.

[sugat009]

issue (blocking): This misplaces PR #10124's core logic and miscredits the file. src/input.ts never contained the parent fetch, the contact_type check, or the lineage shaping, and #10124 did not add the file.

What the history shows:

• input.ts was added by PR #10094 (commit 806456120, 2025-06-27) and at that point held only input-shape validation (validateContactInput, validateReportInput, reported_date format checks).
• PR #10124's entire diff to input.ts is +6/-1 (git diff 95153376d^1 95153376d -- shared-libs/cht-datasource/src/input.ts): it adds contact: string to ReportInput and a required-contact check.
• In #10124 the parent fetch, contact_type-vs-allowed-parents check, and dehydrated-lineage construction are module-local helpers duplicated per file: ensureHasValidParentFieldAndReturnParentDoc/validatePersonParent/appendParent in local/person.ts, a separate copy of ensureHasValidParentFieldAndReturnParentDoc plus validateParentPresence/appendParent/appendContact in local/place.ts, and appendContact in local/report.ts. Nothing is centralized or reused across modules at that point.
• Centralization came later on the feature branch (PR #10308, PR #10522): the logic moved into local/libs/lineage.ts (assertHasValidParentType, minifyLineage) and local/libs/doc.ts (getDocsByIds), and input.ts was reduced to types only before the branch squash-merged to master as PR #10083.

Suggested rewrite for lines 75 and 83: attribute the fetch/check/shaping to per-module helpers in local/person.ts, local/place.ts, and local/report.ts (duplicated in #10124, centralized into local/libs/lineage.ts by later feature-branch refactors). For line 110, change the attribution to shared-libs/cht-datasource/src/input.ts (added in PR #10094, touched by PR #10124). The existing caveat that none of this exists at the draft's own anchor (e0ecefed4) is correct and can stay.

[sugat009]

issue (non-blocking): the state description is inverted, though the guidance is right and should stay. PR #10432 is not an "open PR ... not merged": GitHub has it merged=true on 2025-12-19 into the epic branch 10140_previous-month-targets. What actually happened is sharper: it merged into the epic, then its content was dropped before the squash. #10423's file list carries zero of its files, the contact-UUID vocabulary is zero-hit on master, and the epic branch has since been deleted, so the PR's own head is indeed the only place the code exists. "Do not treat as available API" stays correct. Suggested banner: "Merged into the 10140_previous-month-targets epic branch on 2025-12-19 (PR #10432), but dropped before the epic's squash: #10423 carries none of its files and the vocabulary is zero-hit on master. Do not treat as available API." For the record, the banner's other claim verified cleanly: master's target-aggregates.service.ts:35 is bindGenerator(Target.v1.getAll), introduced by the #10423 squash, and TargetInterval.v1.getAll exists nowhere on master.

[sugat009]

issue (blocking): Line 73 says all listed files "still exist on master", but config/standard/app_settings.json does not. The entire standard config was removed from cht-core by medic/cht-core#8762 (issue #8757, commit 3f7f6d6e3, merged 2024-01-10); config/standard/ on origin/master now contains only a readme.md pointer. Verified the other 16 listed paths do exist on origin/master (6eb2ac0f1) with no barcode code, and all 17 existed at the draft's anchor 59a1dbd2, so only this sentence needs fixing. Suggested wording: "All of them still exist on master except config/standard/app_settings.json (the standard config was removed by #8762 in January 2024), and none of the survivors carries any barcode code there."

[sugat009]

issue (blocking) [agent-memory/domains/contacts/issues/9835-cht-datasource-create-update-contacts.md:76]: The permission enumeration is wrong for five of the six write endpoints. At the #10083 merge commit (f382785be) and unchanged on current master (6eb2ac0f1), the checks are: person create hasAny ['can_create_people', 'can_edit'] (person.js:152), person update hasAny ['can_update_people', 'can_edit'] (person.js:202), place create hasAny ['can_create_places', 'can_edit'] (place.js:151), place update hasAny ['can_update_places', 'can_edit'] (place.js:209), report create hasAny ['can_create_records', 'can_edit'] (report.js:268), report update hasAny ['can_update_reports', 'can_edit'] (report.js:326), all with isOnline: true. The removed read permission was also can_view_reports for report endpoints, not can_view_contacts. Suggested replacement: "Permission fix (PR #10522): write endpoints no longer require the read permission (can_view_contacts for person/place, can_view_reports for report); each requires an online user with can_edit or the entity-specific write permission (can_create_people/can_update_people, can_create_places/can_update_places, can_create_records/can_update_reports)." Relatedly, the Solution paragraph's claim that PR #10222 made person/place/report honor can_edit is imprecise: #10222's diff adds can_edit for person and place only; report gained can_edit in #10522, which also fixed report update's constant from can_update_records to can_update_reports.

suggestion (non-blocking) [agent-memory/domains/contacts/issues/9835-cht-datasource-create-update-contacts.md:11]: The Solution section leads with PR #10522 (feat(#9835): refactor create/update cht-datasource apis, merged into the feature branch 2026-03-03) and describes its changes in detail, but source_prs omits it. Add "medic/cht-core#10522" to source_prs.

(Nitpick about the Domain note's "its anchor PR" wording: drop. The draft has an identifiable singular anchor PR, #10083, the only source PR merged to master; the claim attached to it is true, and the identical boilerplate appears in sibling multi-PR drafts 10043 and 10057.)

(Anchored here because line 76, where the enumeration lives, is outside this round's diff hunks.)

[sugat009]

issue (non-blocking): The stated signature Person.v1.getPage(limit, skip) omits the required first argument. At this draft's anchor (b20dc2297, PR #9266's merge commit), the curried function is (personType: ContactTypeQualifier, limit = 100, skip = 0) and assertTypeQualifier(personType) throws when the qualifier is missing, so a two-argument call was never valid, even as of this PR. The Design Choices claim that "callers can omit arguments" (line 77) holds for limit/skip only, never for personType. Suggestion: write the signature as Person.v1.getPage(personType, limit, skip) and state that personType is a mandatory ContactTypeQualifier (see qualifier.ts, already listed in entities). Separately, since the frontmatter says stale: false, consider a one-line drift note: the skip parameter is accurate for this PR, but PR #9281 replaced it with cursor paging on the same feature branch before it reached master (34dd0303c via #9311), and current master is (personType, cursor = null, limit = DEFAULT_DOCS_PAGE_LIMIT).