chore(memory): promote strong-fit configuration drafts from memory-pipeline for review

[Hareet]

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

Categories: feature (6), bug (4)
Themes: translations & RTL support, branding/partners doc validation, header-tab ordering, UI-extension service-worker rebuilds.

All 10 carry domainFit: strong + a ## Domain Rationale section. 18 weak-fit drafts deferred to Stream C — configuration was a catch-all in this run (64% weak), so this PR is intentionally the distilled minority.

• 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 4 of 10 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:

• 10198-fix8026-validate-empty-branding-doc.md stores issueNumber: 10198 / issueUrl: .../issues/10198, but 10198 is the merge PR ("fix(#8026): validate empty branding doc"). The real issue is #8026 (closed): "Admin app fails to update branding if existing document is malformed".
• 9407-fix9406-disable-unsupported-languages.md stores issueNumber: 9407 / issueUrl: .../issues/9407, but 9407 is the merge PR ("fix(#9406): disable unsupported languages"). The real issue is #9406 (closed): "Update default configurations to disable unsupported languages".

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.

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 Same as the others.

Rebased onto main and addressed the review: identity keys relinked via #129's tool (4 files, same treatment as merged #129); all 10 PR→issue mappings re-verified against the cht-core API, zero mismatches. The deterministic relink supersedes the "regenerate and re-promote" suggestion — #129's merge established that approach. Also scrubbed process narrative from the prose and added the optional source_prs schema field used by the sibling seeders' duplicate collapses.

[sugat009]

Content re-review. Identity/dedup/schema clean. Remaining (mostly distillation fidelity):

• issue (accuracy): 10604, 8722, 11021 carry wrong/fabricated technical detail (inline).
• nitpick (leakage): 9696 Domain Rationale ("…the seed", "explicit strong fit"); strip.
• nitpick: 9696↔9727 are an in-batch RTL/translations pair (issues #9682/#9683) but related_issues doesn't cross-link them; backfill.

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.

[Hareet]

Re-verified every factual claim in these drafts against the cht-core commit each was distilled from, rather than only the three items raised in review. Confirmed against source, with 13 corrections applied and one draft removed. After the removal the branch stands at 110 verified claims and no contradicted ones. These scripts from WIP were used.

Each correction below has the command that establishes it.

---

10604 — the draft described the wrong cause and the wrong fix

Beyond the view name, two larger problems:

There was no view-path migration. The stated root cause never happened — the view was never renamed or removed and is still present with ~20 consumers. What actually broke the page is #10255 removing the translations special case from the view's map function:

git -C $CORE log --format='%h %ci %s' 06d2e3abe2 -- ddocs/medic-db/medic-client/views/doc_by_type/
# de02d8421 2025-09-09 chore(#8157): remove use of translationdoc.enabled (#10255)

git -C $CORE show de02d8421 -- ddocs/medic-db/medic-client/views/doc_by_type/map.js
# removes: if (doc.type === 'translations') { emit(['translations', doc.enabled], {code,name}); return; }

That PR updated display-languages.js and display-translations.js but missed admin/src/js/services/languages.js, which kept querying key: ['translations', true] and got zero rows.

The fix is not a path correction. It abandons the view entirely:

git -C $CORE show 06d2e3abe2 -- admin/src/js/services/languages.js
# -  .query('medic-client/doc_by_type', { key: ['translations', true] })
# +  .allDocs({ start_key: 'messages-', end_key: 'messages-￰', include_docs: true })
# -  return _.map(result.rows, 'value');
# +  return result.rows.map(row => ({ code: row.doc.code, name: row.doc.name }));

And the spec was added, not updated — the service had no test before this PR:

git -C $CORE diff-tree --no-commit-id --name-status -r 06d2e3abe2
# M  admin/src/js/services/languages.js
# A  admin/tests/unit/services/languages.spec.js

The view name is corrected to doc_by_type throughout, and related_workflows: [data-migration] is dropped since no migration is involved.

8722 — the migration was deleted, not preserved

git -C $CORE diff-tree -M --no-commit-id --name-status -r d93b9162e2 -- api/src/migrations/
# D  api/src/migrations/add-branding-doc.js
# A  api/src/migrations/add-cht-branding-doc.js

Corrected, the deleted file removed from entities, and A/D status noted in Related Files. Also dropped a ui-extensions workflow tag from a 2023 draft — that workstream first appears 2026-03-30:

git -C $CORE log --all --reverse --format='%h %ci' -- api/src/services/ui-extension.js | head -1

9727 — rtl resolution misattributed

git -C $CORE grep -n -F -w setRtlLanguage 2175676e28
# providers/translation-loader.provider.ts:50   doc.rtl && this.languageService.setRtlLanguage(locale)
# services/language.service.ts:107              setRtlLanguage(code) { ... }

language.service.ts holds an in-memory registry and performs no document access; the provider reads doc.rtl. Anachronistic ui-extensions tag dropped here too (anchor is 2025-03-11).

10278 / 10198 — scope overstated

git -C $CORE show 9b26cbd0e2 -- admin/src/js/controllers/images-partners.js | grep '^+' | grep -v '^+++'
# exactly one added line, inside addAttachment; the load path is untouched

git -C $CORE show d9b2ef5750 -- admin/src/templates/images_branding.html | grep '^+' | grep -v '^+++'
# ng-if="favicon" / ng-if="icon"   ← where template safety actually comes from, not scaffolded keys

Review nitpicks

Classifier scaffolding stripped from 9696's Domain Rationale, and 9696 ↔ 9727 cross-linked in related_issues as the RTL/translations pair.

---

What was confirmed correct

110 claims verified positively across the nine remaining drafts, not merely "no error found" — Related-File membership with A/M/D status on every draft, and every named symbol located in the file the draft attributes it to. The strongest were 9727 (23), 8722 (20), 10604 (15 after correction), 10278 (14), 10198 (13). Nine claims remain unverifiable, all in 11057.

Drafts whose provenance I could not verify

Two drafts had no resolvable anchor, and this is not clone staleness: their PR numbers are stamped nowhere in history, even on a same-day clone. One is removed; the other is flagged.

11021 — removed from this PR: the described feature is not in cht-core.

git -C $CORE grep -n "startsWith" origin/master -- api/src/services/config-watcher.js
#   :167  change.id.startsWith(PREFIXES.TRANSLATIONS)
#   :171  change.id.startsWith('form:')      ← no UI-extension branch
git -C $CORE log --all --oneline --fixed-strings --grep="#11018"    # empty

PREFIXES.UI_EXTENSION exists in shared-libs/constants, but config-watcher.js has no UI-extension dispatch and nothing references the issue. That is the same situation you flagged on the smsparser draft — proposed work described as completed and tested — so I have dropped the draft rather than ship a memory asserting behaviour the codebase does not have. Worth re-distilling once the change merges.

Removing it also retired the one correction on this branch that would have had to be guessed: the draft's 'ui-extension:' literal could not be checked either way, since master carries no PREFIXES.UI_EXTENSION usage to compare against.

11057 — mechanism real, attribution wrong.

git -C $CORE grep -n -F -w weight origin/master -- webapp/src/ts/services/header-tabs.service.ts   # :23 :32 :41
git -C $CORE log --oneline -1 origin/master -- webapp/src/ts/services/header-tabs.service.ts
# 180c29ecf feat(#10224): support ui-extensions (#11050)

The weight ordering is real, but it arrived in #11050, not #11057. Worth confirming the source_pr before this one is trusted for provenance.

Nothing in 11057 was edited on the strength of an unverifiable claim — its substance checks out, only its source_pr is in doubt.

[Hareet]

Before the re-review starts: I audited my own verification comment above and found two wrong conclusions in it, plus one stale claim it let through. Corrections landed in 3cd4124; validate-schema still passes (73/0), and the clone-scoping blind spot itself is now fixed in the verification tooling on #145 (adfb256). Same format as before — each point carries the command that establishes it.

The "unresolvable anchors" were real all along — my clone-scoped tooling was the problem

I wrote that 11057 and 11021 "had no resolvable anchor" and doubted source_pr: #11057. That was wrong. Both PRs are real and merged — into the 10224-ui-extensions feature branch, which reached master as the #11050 squash. The child PRs' merge commits exist only on the (deleted) feature branch, which is why git log --grep on a clone finds nothing:

curl -s https://api.github.com/repos/medic/cht-core/pulls/11057 | jq '{state, merged, base: .base.ref, merge_commit_sha}'
# "closed", true, "10224-ui-extensions", "46c8f7c8e43a969d9ecd12c65d3816b19664fd63"  ← exactly the draft's source_sha

git -C $CORE log -1 --format='%h %ci %s' 180c29ecf
# 180c29ecf 2026-06-22 feat(#10224): support ui-extensions (#11050)   ← how it reached master

The nine claims I logged as "unverifiable, all in 11057" are now verified, all true, against both the PR diff and current master:

git -C $CORE grep -n -w weight origin/master -- webapp/src/ts/services/header-tabs.service.ts
# :23–:57 defaults · :133 header_tabs app-settings override · :150 UI-extension weight · :162,:185 sorts

git -C $CORE grep -n SidebarTab origin/master -- webapp/src/ts/components/sidebar-menu/sidebar-menu.component.ts
# :23,:50 — the sidebar refactor (hardcoded TAB_MENU_OPTIONS → pre-ordered SidebarTab list) survived the squash

Blockers #10672/#10901 and the forum request are verbatim in issue #10908's body; cht-docs#2213 and the "most unit tests by Claude" disclosure are verbatim in PR #11057's. Draft change in 3cd4124: source_prs: [#11057, #11050] (the schema field's multi-PR-epic case) plus a Related Issues note carrying the master-reachable squash commit, so the anchor now resolves from a plain clone.

11021 stays dropped, but for a corrected reason. It was not the smsparser case — the work was real, merged into the epic, and tested. It was superseded during the epic's evolution: the #11050 squash lands no UI-extension dispatch in config-watcher.js and even removes the older extension-libs service-worker hooks. Master has no rebuild-SW-on-ui-extension-change behavior, so the memory stays out; nothing to re-distill unless that behavior returns.

curl -s https://api.github.com/repos/medic/cht-core/pulls/11021 | jq '{state, merged, base: .base.ref}'
# "closed", true, "10224-ui-extensions"

git -C $CORE show 180c29ecf -- api/src/services/config-watcher.js
# removals only: extensionLibs require, isLibChange dispatch, handleLibsChanges

One claim my pass verified against the wrong era — now time-scoped

10604 said the view "still exists on master with roughly fifteen consumers" (my comment above said ~20). Both figures were measured at the source commit and are stale on today's master: #10822 (2026-07-01) narrowed doc_by_type to indexing only form/user-settings and moved every remaining consumer off it.

git -C $CORE grep -l doc_by_type 06d2e3abe2 | wc -l     # 18 — at the fix
git -C $CORE grep -l doc_by_type origin/master | wc -l  # 0  — today
git -C $CORE log -1 --format='%h %ci %s' 57ea9228b
# 57ea9228b 2026-07-01 feat(#10638): not indexing common documents in doc_by_type (#10822)

The draft sentence is now era-scoped: 18 referencing files at the time of the fix, with the #10822 note for current master.

Three wording fixes in the same commit

• 10278 — "a browserify-compatibility const was documented": what the review thread actually shows is that the suggested res?.resources one-liner broke the admin browserify build, which is why the Admin service keeps the ES5 guard while the Angular-CLI-built webapp uses res?.resources ?? {} (thread). Reworded accordingly.
• 10555 — the AI disclosure is a section of the PR description, not a comment in the properties file (the file has zero comment lines). Also stripped the "not a catch-all pick" triage vocabulary from the Domain Rationale — same leakage class you flagged on 9696.
• 8722 — completed the (added)/(deleted) annotations on the logo assets in Related Files.

Updated tally, from a fresh ground-claims run with the epic-aware resolver (#145's adfb256) against the same cht-core checkout as before (1f3e56f226): 9 drafts, 122 grounded / 0 ungrounded / 0 unverifiable / 0 anchor-unusable (was 110 / 0 / 9). The nine previously-unverifiable claims now ground with 11057 anchored at the epic squash — the report records the anchor as 180c29ecf with the note "resolved via GitHub API: medic/cht-core#11057 merged into 10224-ui-extensions; anchored at the squash of #11050". One previously-"verified" claim was contradicted by current master and is corrected above; everything else stands as posted.

[sugat009]

Round 3 on the reworked head. All five findings from my last round are verified fixed: the 10604 rewrite is now the model for how these drafts should read (correct view name, accurate description of the allDocs replacement, time-scoped staleness), 8722 states the add-branding-doc.js deletion correctly, the 9696/9727 cross-links landed, the scaffolding is gone, and deleting 11021 rather than correcting it was the right call, since the hook it documented never reached master.

Requesting changes on the two residual items plus two nitpicks inline. Both residuals are the same secondary-section staleness pattern flagged in more volume on #120.

[Hareet]

All four items are fixed, and chasing the cause behind them turned up one more instance of the same class in a draft you had not flagged — that one is the reason this reply is longer than four lines. Head is b8004ca.

Your items

10198 Testing — your suggestion, verbatim. The merged spec does cover both cases (should not fail when branding doc is empty at :41, should not fail when resources is null at :53 in d9b2ef575), so "one related case is not covered" was a mid-review leftover with no referent.

10278 present-tense dead path — time-scoped in 10604's style, and the drift check found the problem was wider than the four lines you cited: webapp/tests/karma/ts/services/resource-icon.service.spec.ts is also gone, replaced by custom-resource.service.spec.ts in the same #11050 commit. Both now carry the qualification, with one note in Code Patterns explaining that the Admin service survived while the webapp side was replaced.

git -C $CORE cat-file -e origin/master:webapp/src/ts/services/resource-icons.service.ts || echo absent
git -C $CORE log --oneline --diff-filter=D -1 -- webapp/src/ts/services/resource-icons.service.ts
# 180c29ecf feat(#10224): support ui-extensions (#11050)

11057 source_prs — you are right that #11050 does not resolve #10908, so under that field's description it does not belong there. I removed source_prs from the draft entirely rather than trimming it to a single entry, since with source_pr: medic/cht-core#11057 present the array carried nothing. The epic provenance stays in the Related Issues prose where it reads as context rather than as a resolution claim. Worth noting it costs nothing mechanically: the anchor resolver reaches the same commit through #11057's base branch, so grounding still anchors this draft at 180c29ecf without the metadata.

lastUpdated — 10198, 9696 and 9727 bumped. A stale-timestamp check now enforces this (lastUpdated must not predate the file's last commit), which promptly caught a fourth I had missed, 9407, and then caught my first attempt at fixing it: I had set it to the date of the last content change, but setting the stamp is itself an edit, so the rule that actually holds is "touch the file, stamp it today".

The item you did not flag

Following your diagnosis as a class rather than a checklist, I built a check for it — an LLM identifies contradicting pairs and must quote both sides verbatim, then the script verifies mechanically that both quotes occur in the file and discards any that do not. Run blind across all nine configuration drafts it found exactly one thing, in 10198, which the round-2 grounding pass had half-corrected:

• Solution (L53): "Template safety comes from new ng-if="favicon" / ng-if="icon" attributes on the two <img> tags, not from scaffolded keys."
• Design Choices (L61): "the controller defensively scaffolds the minimum keys the template requires"

The summary and Code Patterns carried the same stale mechanism. Verified against d9b2ef575: the controller scaffolds only resources, guards the favicon/icon assignments behind if (doc._attachments && doc.resources) so they stay undefined, and the template is protected by the two new ng-if attributes. All four sections now say that. This is the same shape you found in volume on #120 — it was here too, one draft deep.

Gate

validate-schema 73/0. verify-drafts --online (identity, duplicates, near-miss symbols, leakage, cross-references, timestamps): 0 blocking, 0 warnings across all nine. ground-claims: 117 grounded, 0 ungrounded, 0 unverifiable, 0 anchor-unusable, 0 stale-as-written, 0 unmatched code fences, all nine drafts anchored — 11057 via its epic squash 180c29ecf, as described above, the other eight at their own commits. Coherence: 0 contradictions.

Two things I would rather say than have you find:

• The coherence check samples rather than exhausts. Three passes over the messaging batch returned pairs with different membership each time, so a single clean pass is weak evidence. Configuration has been clean across multiple passes and an independent audit, which is why I am reporting it as clean rather than proven.
• The cross-reference audit initially flagged your #10901 "Blocker for #10908" gloss as a mismatch. That was my check being wrong, not the draft: a gloss describing a relationship is not a paraphrase of a title, and relationship glosses are now exempt from that comparison.

[sugat009]

Approving. All four round-3 comments verified fixed at b8004ca:

• 10198's stale "One related case is not covered by the fix" is gone, replaced with accurate coverage of both the empty-doc and null-resources cases.
• 10278 is now properly time-scoped, with a "Note on paths" paragraph naming custom-resource.service.ts, PR #11050 and commit 180c29ecf, and both Related Files entries annotated. This is the 10604 pattern applied correctly, and it is the model I would point the other domain branches at.
• 11057's stray source_prs entry for #11050 is removed.
• The three stale lastUpdated values are bumped to 2026-07-30.

Zero residual findings. CI green at b8004ca.