chore(memory): promote strong-fit forms-and-reports drafts from memory-pipeline for review

[Hareet]

Promotes 47 strong-fit forms-and-reports drafts from agent-memory/_pending/ into agent-memory/domains/forms-and-reports/issues/ for squad content review.

Categories: feature (21), bug (20), improvement (6)
Themes: Enketo widgets & XPath extensions, cht-datasource report create/update, SMS parser, form validation/submission hardening.

All 47 carry domainFit: strong + a ## Domain Rationale section. 5 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.

[Hareet]

Needs to be rebased with main after #119 is merged

[sugat009]

Heads up, this one currently has merge conflicts with its base and will need a rebase before it can merge.

[sugat009]

Content review. Prose fidelity is high across a wide sample (10022, 10246, 10730, 8746 all verified faithful). Blockers:

• issue (blocking): identity keys record the PR number on 25 of 47 drafts (verified); 8740 closes no tracked issue.
• issue (blocking): 6 duplicate clusters (13 files): issue 8745 = [8746, 8748, 8752], 9429 = [9434, 9436], 9604 = [9608, 9610], 9835 = [10022, 10246], 10040 = [10071, 10099], 10041 = [10180, 10200]. Plus near-duplicate content: 10922 (#10904) and 11116 (#10700) distill the same attachment-routing feature.
• issue: related_issues: [] empty on every draft; domainFit: strong on every draft. Forced picks: 9512 (route guard across seven *.routes.ts, no form-engine code), 9513 (once-a-day display gating), 11023 (geolocation.service.ts only), 9641 (API startup resilience). Borderline: 9592 (training-materials page that does include training forms).
• nitpick: classifier/seed reasoning leaks into ## Domain Rationale of the 8745 cluster ("seed-3 principle").
• nitpick: category vs slug/PR type: 9414 is bug but slug feat9413; 9840 is feature but the PR is a fix (its key 9844 is correct).

Clean bill: no secrets, no PII, schema 100% valid.

[sugat009]

issue: 8746/8748/8752 are three PRs (base + two backports) for one issue #8745, distilled as three separate memories; they should collapse to one. The "## Domain Rationale" here also leaks the internal "seed-3 principle" phrasing.

[sugat009]

issue (domain-fit): this is an Angular canDeactivate route guard wired across seven *.routes.ts (about/analytics/contacts/messages/reports/tasks); it is navigation plumbing, not forms-and-reports.

[sugat009]

issue: near-duplicate of 10922 (both route Enketo attachments to the owning sub-doc, same fixtures); 10922 closes child #10904, 11116 targets epic #10700.

[sugat009]

Proposal: a first-class data-access domain + a weighted secondaryDomains[] field

This is a cross-cutting taxonomy/schema item spanning #122, #123, #132 (and the merged #129). Not blocking any single PR — it is the decision the team already partly made in #86.

The problem. cht-datasource work has no clean home in the 9 domains, so library-extension drafts are scattered: #122 (10064/10071/10180, plus the dropped 10022/10246), #123 (10390; 10432 relocated to contacts), #132 (10043 PersonQualifier, 10057 PlaceQualifier, 9266/9281 getPeople). This is the context-selection gap raised in #86 (the distiller injects the wrong patterns for these tickets).

Extend vs use (classification rule): a draft whose primary work extends the cht-datasource library API — its anchor PR touches only shared-libs/cht-datasource — gets data-access as primary domain; a draft that merely consumes cht-datasource keeps its product domain with subDomain: cht-datasource. E.g. 10071 (createReport) is 100% cht-datasource → extend; 9755 touches no cht-datasource files → use.

Already agreed. Hareet proposed a first-class data-access domain (organized on cht-core #11174's Contact.v1/Report.v1 / Person/Place hierarchy), and we settled it in the team meeting to add it, to be populated by re-running the #119 pipeline over the datasource tickets, sequenced after #127 Langfuse for before/after traces. No tracker for it surfaces yet — worth filing.

The secondary-domain piece. Some datasource work is about a product area (e.g. 10071 = data-access primary, forms-and-reports secondary). The schema cannot express that today (subDomain is a free-text sub-area; the code-encoded rule is "one primary domain + related_workflows"). Proposed: add a secondaryDomains: CHTDomain[] field — reuses the CHTDomain enum, array-valued, and carries "smaller power" in retrieval (the consumer, calculateSimilarityScore / research + code-gen, weights a primary-domain match fully and a secondary-domain match at a fraction). This recovers the cross-domain breadth singular domain loses (my #135 comment) without two co-equal primaries. Keep it distinct from related_workflows (a CHTWorkflow) and related_domains (the domain graph). Do not auto-emit it from the distiller initially — seed it human-set on the datasource cluster until primary-domain accuracy is solid.

Recommendation. Ship data-access + secondaryDomains as one coordinated schema/taxonomy PR (alongside the agreed data-access work, not through these content chores), then re-key the extenders (domain: data-access + secondaryDomains: [<product>]) and keep consumers in their product domain with subDomain: cht-datasource. NB the 10022/10246 report-datasource content already lives in #132's 9835 contacts draft — more evidence it wants a data-access home.

[sugat009]

Content re-review (post-rework). Identity/dedup are clean. Remaining:

• issue (accuracy): 9227 names a non-existent XPath function (inline).
• issue (domain): the createReport / report-update drafts (10064/10071/10180) extend the cht-datasource library and belong in the agreed data-access domain (inline on 10071).
• nitpick (domainFit): 9592 is strong but is the same training/navigation class as its weak siblings 9512/9513 (inline).
• nitpick (leakage): 11165 Domain Rationale scaffolding; strip.
• (10922/11116: only a minor gap — the contacts-side child issue 10903 has no draft; listing 11116 in source_prs is defensible.)

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 a separate detailed comment on this PR.

[sugat009]

issue (accuracy): this draft (Solution section, ~L30) names the XPath function cht:luhn-check, but the real function is cht:validate-luhn (registered in PR #9220 as 'cht:validate-luhn': luhn; current webapp/src/js/enketo/medic-xpath-extensions.js and the CHT docs use it, added 4.10.0). cht:luhn-check never existed — an agent grepping the corpus would find a non-existent function. Please rename throughout.

[sugat009]

issue (domain): this PR (and 10064/10180) touches only shared-libs/cht-datasource — createReport/report-update library API. Per the team-agreed data-access domain (#86), these library-extension drafts belong in data-access with secondaryDomains: [forms-and-reports], not primary forms-and-reports. See the detailed data-access proposal comment on this PR.

[sugat009]

nitpick (domainFit): graded strong, but this is a training-materials/navigation page — the same class as 9512/9513, which are weak. Re-grade to weak for consistency.

[Hareet]

Request for re-review

All four items are addressed — one of them by disagreeing with you, with reasons
below. Beyond them, running this branch through the same gate #123 got turned up
a long tail: 19 commits across the batch, most of it found by the gate rather
than by the review, and a good deal of it introduced by earlier fixes in this
same sequence.

Two of those commits are filename corrections rather than prose. 8740 was keyed
in its filename to 7462 ("Make code for Enketo forms reusable outside cht-core")
while its frontmatter, correctly, says 7599 ("Update to latest enketo-core") —
renamed to match. 8656 was renamed from …-make-xpath-date-extensions-consistent
to …-make-xpath-date-tests-timezone-independent, because the change is a test
determinism fix and the old name described a source change it does not make.

Your four

9227, the XPath function that never existed — fixed. The registration is
'cht:validate-luhn': luhn at medic-xpath-extensions.js:226; cht:luhn-check
is zero-hit in cht-core.

git -C $CORE grep -n 'validate-luhn' origin/master -- webapp/src/js/enketo/medic-xpath-extensions.js
#   226:    'cht:validate-luhn': luhn,

Worth flagging that this one is not confined to the PR: 9227 is one of ten
hand-authored drafts already on main, and the landed copy still says
cht:luhn-check twice. Merging this repairs the live corpus, so it is a slightly
higher-value merge than the diff suggests.

10064 / 10071 / 10180 → data-access — deferred, and now recorded in
the drafts rather than only in this thread. Same call as #123's 10390, on your
own recommendation:

Ship data-access + secondaryDomains as one coordinated schema/taxonomy PR
… Not blocking any single PR.

Neither the enum value nor the secondaryDomains field exists in the schema yet,
so a re-key here would be a content PR inventing taxonomy. What was wrong is that
a reader of the corpus saw three cht-datasource extenders keyed forms-and-reports
with no explanation. Each now records in Domain Rationale that the re-key was
requested and deliberately not made here.

One correction while doing it: the premise does not hold uniformly. 10071 and
10180 are pure shared-libs/cht-datasource, but 10064 is not — its diff
also carries api/src/controllers/report.js, shared-libs/lineage/src/index.d.ts,
two webapp files and integration tests. I had written "entirely
shared-libs/cht-datasource" into its Domain Rationale on your description, and
three consecutive coherence passes caught it against the draft's own Solution
section. 10064's case for data-access is therefore weaker than its two
siblings', which seems worth knowing when the taxonomy PR gets written.

10071 had no Domain Rationale section at all — the one draft your domain
comment was actually filed against, and the section where the answer belongs. It
has one now. It was the only machine-distilled draft missing it; the other ten
without it are the hand-authored files, which is the two-schemas item you already
flagged as not blocking.

9592 domainFit — this is the one I'd push back on. It is not the same
class as 9512/9513. Those two are navigation and scheduling: 9512 is a
canDeactivate guard across *.routes.ts, and 9513 gates display frequency in
training-cards.service.ts, which references no form-engine code at all. 9592
adds training-cards-form.component.ts, which owns the Enketo render/save
lifecycle:

git -C $CORE grep -n 'renderForm\|saveForm\|formService\.' origin/master \
  -- webapp/src/ts/components/training-cards-form/training-cards-form.component.ts
#   124:  private async renderForm(formConfig: FormConfig) {
#   130:      this.form = await this.formService.render(formContext);
#   188:  async saveForm() {
git -C $CORE grep -c 'FormService' origin/master -- webapp/src/ts/services/training-cards.service.ts
#   (no match)

So the grading tracks a real distinction rather than an inconsistency: this PR
builds a form-rendering surface, its siblings do not. The Domain Rationale now
spells that out explicitly so the next reader does not have to re-derive it.
Happy to drop it to weak if you would rather the training-cards cluster be
uniform — say the word.

11165 Domain Rationale scaffolding — stripped.

Round-1 items, re-verified rather than assumed

• 8746/8748/8752 collapse to a single draft keyed to issue 8745.
• 9512 is weak.
• 11116 has no standalone draft; it is folded into 10922 via source_prs,
  which is the treatment you called defensible.

What the gate found that the review did not

The bulk of the 19 commits. Grouped by class, since the individual items are in
the commit messages:

• Fabricated or unresolvable symbols and paths — 10917 described the widget
  as renamed from hidden-field-list.js, a file added in no commit on any ref;
  the widget landed as hidden-group.js outright, and the narrower name existed
  only in review. (Worth being precise, since I got this wrong myself while
  checking it: HiddenFieldList is a real cht-core symbol — it lived in
  enketo-translation/enketo-form-manager and was removed by cccce201e. It
  has nothing to do with this widget, which is why the draft now speaks only of
  the name the widget itself carried in review.) Also: enketo-core module paths
  written as though they were repo paths, and a bare contact-photo.component.ts
  when the resolvable path is under webapp/src/ts/components/contact-photo/.
• Claims true of one PR attributed to another across the epic-branch drafts,
  where #10071/#10099 and #10180/#10200 were children of the 9835 epic
  and reach master only through squash f382785be.
• Self-contradiction between sections — the highest-yield class here as on
  chore(memory): promote strong-fit tasks-and-targets drafts from memory-pipeline for review #123. Example: 10922 asserted the ancestor walk "ensures attachments land on
  the structurally-correct owner" and then, in the same paragraph, gave the
  limitation that defeats it (the walk starts from a node found by filename, so
  two same-named files land on the same sub-doc).
• Fixes that introduced new defects. Several commits exist only to repair
  earlier commits in this sequence — including one that broke a claim that had
  been correct, and three where a fix introduced a literal matching nothing
  (postResource('api/v1/person') when the real call takes the context first).
  This is the single most common source of findings on this branch, ahead of
  anything present in the original drafts.

The attribution sweep, run over this batch

Your closing note on #123 asked for every "this PR added X" and "on master Y"
sentence to be checked against gh pr view --json files and
git grep origin/master. That was mechanised for tasks-and-targets; it has now
been run here too, over all 48 cht-core PRs these 41 drafts reference.

63 candidates, no real defects. 53 from the file-status screen, 10 from the
symbol screen, each adjudicated by hand. They fall into three artifact classes:

• "added a symbol in/to a file the PR modified" — "Added a Karma unit test
  in form.service.spec.ts" (10 hits);
• verbs inside filenames — reports-**add**.component.ts matches "add",
  with-**extension**-libs.wdio-spec.js matches "extension" (6 hits);
• prose about other actors — ODK adding a trigger column, Chrome dropping
  DOMSubtreeModified, the epic squash adding input.ts.

The one that needed real checking was 10180's Input.v1.UpdateReportInput,
absent from #10180's own patch. It is genuine — input.ts:36 and
local/report.ts:63 on master — and absent from that PR only because the epic
squash introduced input.ts, which the draft's Provenance section already scopes.

On convergence, and why this round exists

The previous stopping point was not converged, and the pattern is worth naming
because it will recur. Passes g19/c19 came back clean and the run ended
there. But g17–g19 and c17–c19 all ran after the final commit, and
c17, c18 and g18 had each found something on those same committed bytes
that nobody then acted on. Clean-at-the-end is not the same as converged when
each pass samples a different subset of claims.

Seventeen more findings came out of that, across six further commits. Rather than
list them all — they are in the commit messages — the shape is worth stating: six
of the seventeen were introduced by fixes earlier in this same sequence,
including three of my own. One (10064) I wrote into a Domain Rationale and all
three coherence passes of the next set caught it. Another (10071) had been
flagged by a pass I had already read, and I fixed a different line on the same
draft and left it — a finding read is not a finding fixed.

The three that were outstanding at the start of this round are fixed in it:

• 10922 — the bare contact-photo.component.ts (g18).
• 10922 — the ancestor-walk guarantee vs its own stated limitation (c17).
• 8656 — Root Cause claimed the asMoment() fallthrough "re-parsed the raw
  input … so the two paths could disagree" while Problem said no deployed
  behaviour was wrong. The source settles it for Problem: the branch is
  return moment(r) with const rMoment = moment(r) in scope and r never
  reassigned between them. Same parse, same string, twice — redundant, not
  divergent (c18).

Gate

validate-schema 95/0/3. verify-drafts --online 0 blocking, 0 warnings, 0
unverified across all 41. ground-claims 0 ungrounded, 0 unverifiable, 0
anchor-unusable, 0 unmatched code fences. check-coherence 0 contradictions.

The counts matter less than the sequence. Across this branch the gate has run
30 ground-claims passes and 40 coherence passes. The closing set, against
the committed bytes of e98e5ae, was four consecutive clean coherence passes
(37–40) and two clean ground passes (30–31), with the authenticated online audit
clean over all 41.

That bar exists because of how this corpus actually behaved. Coherence produced
findings in passes 17, 18, 20, 21, 22, 23, 25, 28, 31, 32 and 33 — almost always
after one or two clean passes. A clean pair was never proof here, and the state
this round inherited (g19/c19 clean, run ended) had three findings sitting
unactioned on exactly those bytes. Every closing set was run against frozen,
committed content, and the content was re-frozen after each fix.

One operational note that cost real time: verify-drafts --online was reporting
28–41 drafts unverified and exiting 3. That was GitHub's 60/hour anonymous limit,
not the corpus. Authenticated, the same bytes return 0 unverified and exit 0.
Anything re-running this should export a token first.

Disclosed rather than fixed: 27 stale-as-written items across 10 drafts,
concentrated in the epic-branch content (10922, 10071, 10180) whose paths
and symbols are real on their branches and absent from master. Those drafts carry
explicit "not on master" banners and a Provenance section; 10922 is
stale: true. This is what stale-as-written is for, and it is much heavier here
than on #123 because this domain's datasource work never landed as its own commits.

Merging: behind main, but no conflict

The branch is behind main (#123 landed in the meantime), so it wants an update
before merge. I expected the overlap with the already-landed drafts to be the
tricky part and it is not — I checked instead of assuming:

git merge-tree --write-tree --name-only origin/main memory/promote-forms-and-reports
#   clean; result tree 6deae2f7e1…   (exit 0, no conflict paths)
git diff --name-only $(git merge-base origin/main HEAD)..origin/main \
  -- agent-memory/domains/forms-and-reports/issues/
#   (empty)

Ten of these 41 drafts already exist on main — the hand-authored set
(8225, 8308, 8336, 8806, 9227, 9301, 9974, 10133, 10443,
10509), landed in March by #72 "categorize 10 closed CHT-Core issues (Forms
domain)". main has not touched any of them since, and the merge-base is #129
in July. Only this branch has modified them, so a merge is a fast-forward of
content on those paths: this branch's copies are the ones to keep, and there
is no version to choose between. Nine of the ten differ from main; 8336 is
byte-identical.

That is also why the 9227 fix matters beyond this PR — main's copy is the
March original and still says cht:luhn-check.

One thing for you, not for me

9592 — my disagreement above. If you want uniformity across the
training-cards cluster, I will re-grade it to weak.

[sugat009]

Round 3. All four of my round-2 items are resolved, and two of the resolutions are better than what I asked for: the 9592 keep-strong justification survives full verification (the component really owns the Enketo render/save lifecycle at the anchor, the #9840 rename is real, and neither weak sibling touches form-engine code), and the data-access deferral notes are factually right and mutually consistent. The 8656 and 8740 renames are legitimate title corrections.

Requesting changes on seven items below. Every one was verified with the same protocol: quote at head, check at the draft's own anchor, check on current master, and walk every commit that touched the region in between, so each comment states whether the defect is anchor-level or drift, and includes a suggested rewording. Five are blocking under the accuracy bar (a wrong sign, a wrong mechanism, a wrong attribution, a false read/write claim, and a duplicate identity), two are wording.

One systemic suggestion: standardize a template for epic-branch work, "merged into on ; not on master". The corpus currently errs in both directions (10767 treated an epic-branch merge as shipped; 10922 here calls merged PRs unmerged), and one sentence pattern fixes the class.

[sugat009]

issue (blocking): "model.xml and form.html are not read at all" and "Only one attachment is read" are both false, and not rescueable by time-scoping. PR #10248 itself ADDED the reads: its own diff contains + formsService.getAttachment(doc._id, 'form.html') and + ... 'model.xml' inside updateAttachments, which fetches THREE attachments in one Promise.all (the XForm XML plus these two, as inputs to addGeneratedAttachments). Only two commits have touched generate-xform.js since (#10634 error logging, #10949 xsltproc hardening) and neither touches that region, so master's :254-261 is byte-for-byte what #10248 wrote. The true story is "named reads instead of bulk reads": #10248 stopped loading ALL attachments and switched to fetching exactly three by name. Suggest replacing the two quoted claims with that framing; the write-back description (:243, :247) is correct and stays.

[sugat009]

issue (blocking): Date.prototype.getTimezoneOffset = () => -240 emulates UTC+4, not UTC-4, so "failed for developers outside UTC-4" (summary, line 10; Problem, line 47) is wrong on both sign and scope.

getTimezoneOffset() returns UTC minus local time in minutes, and the distilled commit's own spec proves the convention: at 7202de54, webapp/tests/mocha/unit/enketo/medic-xpath-extensions.spec.js lines 24-25 stub () => -60 and assert getTimezoneOffsetAsTime returns '+01:00', lines 29-30 stub () => 60 and assert '-01:00', so -240 is '+04:00'. Scope is also over-strong: the fix changed no to-bikram-sambat expectations, those same expectations passed pre-fix in CI at UTC, and issue #8556's failures were reported from NZ (+12). The suite was timezone-dependent, passing in some zones (UTC included) and failing in others, not "passing only at UTC-4".

Suggested rewording for both places: "the suite baked timezone-dependent expectations into its cases, so npm run unit-webapp failed in some timezones (e.g. NZ +12, per #8556) while passing in others such as UTC; the fix pins getTimezoneOffset to -240 (emulating UTC+4) so results are identical everywhere."

nitpick: "every #to-bikram-sambat() case" (line 47) is over-broad. At 7202de54 that describe holds 5 conversion cases plus 11 invalid-input cases asserting an empty string, which are timezone-independent; #8556's log shows exactly the 5 conversion cases failing. "Every #to-bikram-sambat() conversion case" would be accurate.

[sugat009]

issue (blocking): The draft contradicts itself about PR #10099, and the place-create attribution at lines 59 and 75 is wrong. Line 69 has it right: #10099 ("feat(#10040): add API support to create reports", merged 2025-07-03 as d19e4e507 on the epic branch, related issue #10040) only touched the person and place create paths to align validation. Its place.ts diff swaps assertPlaceInput for validatePlaceInput on already-standing create wiring, and its place.js diff adds can_create_places to the existing createPlace handler. But line 59 says the place half "is tracked as #10038 (PR #10099)" and line 75 says place.ts's create path "was not [standing], and was added alongside this work by the same #10099". Both are false. The place create path (#10038, "To have API that can create places") was added earlier on the epic branch by PR #10065 ("feat(#10038): implement createPlace local", 169a02355) and PR #10089 ("feat(#10038): add API support to create place", 98a687a80, merged 2025-06-26), with #10094 (806456120) converting the create surface to PlaceInput. By the time #10099 landed, both person and place create paths were standing. Note line 59's "Place had none yet" is true at this draft's anchor cab214534 (no create in place.ts, local/place.ts, or api/src/controllers/place.js there), so only the parenthetical needs fixing. Suggested edits: line 59, replace "(PR #10099)" with "(local PR #10065, API PR #10089)". Line 75, replace the clause after "mirroring person.ts" to say both the person and place create paths were already standing on the epic branch when #10099 landed (place via #10065 and #10089), and #10099 aligned their validation while adding the report path. Line 121 is accurate as written and needs no change.

[sugat009]

suggestion (non-blocking): The "only test change the epic squash carries" half checks out, but the characterization does not. Squash 314e79061a's entire test diff is +2/-2 in tests/e2e/default/enketo/pregnancy-danger-sign-follow-up.wdio-spec.js, and both lines only change excludingEvery('instanceID') to excludingEvery(['instanceID', 'deprecatedID']) in the edit-report assertions, needed because enketo-core v7 populates meta/deprecatedID on edited submissions. That is edit-metadata fallout of the uplift, not relevance/widget coverage. PR 8740's actual widget-behavior test edits, removing the browser.keys('Escape') datepicker workaround in tests/e2e/cht-form/default/death-report.wdio-spec.js and tests/page-objects/default/enketo/delivery.wdio.page.js, netted to zero in the squash (the workaround is absent from 314e79061a^), so they are invisible there. Suggest rewording to: "The epic squash's only test change is tests/e2e/default/enketo/pregnancy-danger-sign-follow-up.wdio-spec.js, which adds 'deprecatedID' to two excludingEvery() exclusion lists because enketo-core v7 sets meta/deprecatedID on edited submissions. PR 8740's own widget-behavior test edits (Escape-workaround removals in death-report.wdio-spec.js and delivery.wdio.page.js) cancelled out within the epic branch and do not appear in the squash."

[sugat009]

issue (non-blocking): The banner's core scoping is verified correct: neither cc34e08664 nor 0df57c664 is an ancestor of origin/master (checked at 6eb2ac0f1), resolveOwnerDoc/findFileNodeByFilename appear nowhere on master (and never have, git log -S is empty), and the two shas really are rebased copies of the same #10922 squash (identical git patch-id --stable 530a4a2a1137, same author, date, and subject). Three details are wrong, though:

1. "Neither PR #10922 nor PR #11116 has been merged" is false. Both are merged=true on GitHub: #10922 merged 2026-05-19 into 10700-photo-capture-in-sub-contacts-and-reports (its squash merge commit is exactly the frontmatter source_sha cc34e08664), and #11116 merged 2026-05-29 into 5.1.2-FR-attachments-for-subcontacts (squash e88c88361). Reword to "merged only into the epic branches, not into master", and update the frontmatter summary's "NOT YET MERGED" and the "unmerged epic branch work" concept to match.
2. "the current branch head 0df57c664" is inaccurate. No ref points at that sha; it is an interior commit of origin/10700-photo-capture, whose head has been bade9485b since 2026-07-10, before this banner's "as of 2026-08-09" stamp. The sha that IS a current branch head is cc34e08664 itself (tip of origin/10700-photo-capture-in-sub-contacts-and-reports). Suggest: "the source_sha cc34e08664 (head of origin/10700-photo-capture-in-sub-contacts-and-reports) and 0df57c664 (a rebased copy on origin/10700-photo-capture) are the same squash".
3. "The commits live only on the epic branches [all three]" overstates. Neither sha is contained in origin/5.1.2-FR-attachments-for-subcontacts; that branch carries the equivalent enketo.service.ts changes via the #11116 squash e88c88361 instead.

[sugat009]

issue (blocking): The ':' separator does not route between Nouveau and the offline path, so this sentence misattributes the routing. On current master, getUuidsPage (shared-libs/cht-datasource/src/local/report.ts) chooses Nouveau vs offline views via useNouveauIndexes(medicDb) (src/local/libs/nouveau.ts), which returns true when the _design/medic-offline-freetext ddoc is absent, i.e. when running server side. The ':' check (isKeyedFreetextQualifier, src/qualifier.ts) only selects keyed exact-match vs prefix range scan inside the offline view path, plus exact_match vs fuzzy syntax inside the Nouveau query. At this draft's anchor (e4d7bdc8, the #9755 merge), Nouveau was not in this code path at all: getUuidsPage queried medic-client/reports_by_freetext, with ':' selecting keyed vs range (Nouveau replaced the views later, in f1bdfc07c, feat(#9542), PR #10201). Suggested rewrite of the second sentence: "Callers therefore no longer choose a view or a key range: cht-datasource decides internally which index a qualifier hits. It uses Nouveau when running server side (no medic-offline-freetext ddoc in the db) and the offline reports_by_freetext view otherwise, doing a keyed lookup when the freetext contains a ':' separator and a prefix range scan when it does not." For the record on the round-2 item: the whitespace-fallback claim was fully removed from all six sections in b82840f, and no residue remains at head; the remaining defect is this replacement sentence, which that same commit introduced.

[sugat009]

issue (blocking): this draft duplicates the identity of a landed contacts draft. Lines 2 and 6 carry id: cht-core-8074 / issueNumber: 8074, which agent-memory/domains/contacts/issues/8074-filter-contact-search-by-parent.md has owned on main since #79 (a0108f7) and which #132 is actively correcting (55dbd0a, 1973657). The key itself is right, cht-core PR 8759's closingIssuesReferences is exactly #8074, and 25e7558 deterministically re-keyed this file from cht-core-8759 to cht-core-8074. But that relink made it a second memory for one issue: the two files share the identical 7-file Related Files set and describe the same change, and they have already diverged once (the set-intersection description was fixed only on the contacts side in 55dbd0a). The 849aa01 collapse pass enforced "one memory per issue" and "no duplicate issueNumbers" within forms-and-reports only, so this cross-domain pair slipped through, the same blind spot 55dbd0a documented for the 8034/data-sync pair.

Suggestion: remove this file from #122 and fold its unique content into the contacts canonical (the specific unit/e2e spec paths in Testing, and the with-same-parent to descendant-of-current-contact naming rationale in Design Choices), mirroring how 849aa01 moved the #9835 pair to "the contacts canonical that owns the issue". Do not re-key it back to 8759; that is a PR, not an issue, which is exactly what 25e7558 fixed, and PR 8759 closes no other issue it could be keyed to. If the team instead decides forms-and-reports should own this memory, that is a relocation of the single canonical draft (a corpus decision touching a landed file), never a second copy. Given this is the second cross-domain duplicate to escape the per-domain gate, a corpus-wide issueNumber uniqueness check in validate-schema would close the class.