Take the client and project names out of the architect and BA rules

[patelanil]

Why

This repo is public. The coach method says client identity never enters a public repo (maarg-agent-coach/docs/coach-method.md:27-28). The architect pack says it again, with the split spelled out:

That plugin repository is PUBLIC. Rules go there, generically worded. The engagement record, the evidence, the client and project names, and the transcripts stay here.

Two files predated that being enforced. This is the older, wider version of the leak that was caught and force-pushed out of #27.

Counts found (re-checked today, not taken on trust)

File	HotWax	project name	other client identifiers
agents/moqui-architect.md	4	1 (pre-order)	—
docs/architect-skill-spec.md	4	5 (Pre-Order)	audited PR number, 4 sponsor ruling ids, 5 client entity/status/field identifiers

Both files also carried co.hotwax.* as a namespace example, which the original counts did not include.

Decision per mention

#	Where	Mention	Decision	Why
A1	agent:153	"A pre-order unit is reserved…"	generalise	An example of statement form. Any commerce fact teaches it equally. Swapped one word; grain noun and cardinality kept.
A2	agent:175-178	"HotWax Commerce OMS is Apache OFBiz's data model…"	generalise, rule kept whole	The load-bearing content is: three entity families, an OFBiz half that is customized, resolve against checked-out code. None of it needs the product name.
A3	agent:177-178	co.hotwax.* as the third family	generalise, namespace slot kept	The third family must survive as a concept. The literal prefix was illustration only — this file's own H6 rule forbids reading the namespace as evidence of family. Replaced with an instruction to read the project's components for it.
A4	agent:187-188	OrderItem.correspondingPoId "is a HotWax field"	replaced — the claim is false	See below.
A5	agent:190	"a HotWax entity can sit in an org.apache.ofbiz.* package"	generalise	"project-custom entity" carries the masquerade rule exactly. Zero loss.
B1	spec H1/H1a/H3/H6	same four mentions	generalise	Same reasoning as A2–A5.
B2	spec, rounds 1–4	project name ×5, audited PR number, ruling ids, client entity/status identifiers	move to the private coach repo	This is engagement record, not rules. Word-swapping the project name would have left the rest of the leak in place.

On the constraint "do not weaken a rule to anonymise it"

No rule was weakened. Checked mechanically: all 21 rules (S1–S10, H1–H10, H1a) and the 5-point review gate are still in the spec, and the heading count is unchanged.

The failure evidence attached to each rule was generalised, not dropped — the shape of a failure is what teaches, the client's identifier is not. Example: "a design doc still told builders to DROP an entity after the sponsor ruled KEEP" teaches H7 exactly as well as the named version did.

One mention is kept, deliberately: AEC1 still names OrderItem.correspondingPoId. That is a stock open-source Apache OFBiz field, not project identity, and the trap it plants is about record grain. The spec now says so explicitly so nobody strips it later by mistake.

A false claim, corrected in both files

Both files taught, as the worked example for "verify the field before writing EXISTS", that OrderItem.correspondingPoId is a custom field and not vanilla OFBiz.

That is wrong. It is a stock Apache OFBiz field:

• defined upstream at applications/datamodel/entitydef/order-entitymodel.xml:557, inside <entity entity-name="OrderItem"> which opens at line 520
• aliased in three upstream entitymodel_view.xml view entities
• read across the upstream ecommerce plugin, order services, and minilang
• that file's git history carries only OFBIZ-* Jira commits, so it tracks upstream and is not a vendor patch

The example that taught "verify before you assert" was itself an unverified assertion.

The rule now teaches the two-directional trap instead: a customized model adds fields upstream never had and repurposes fields upstream already defines, so the field name tells you neither, and provenance is settled by diffing against the forked upstream release. That is stronger than what it replaces, and it needs no product name.

Verified against a local Apache OFBiz checkout. Worth a second pair of eyes on the finding itself, since it contradicts a doctrine line that has stood since 2026-07-11.

What needs the Agent Coach's sign-off

docs/architect-skill-spec.md is Coach-owned, so treat this PR as the proposal for it. Nothing is merged.

1. The identity strip in the rules (H1, H1a, H3, H6) — this executes the Coach's own written rule, so it needs a yes rather than a decision.
2. Moving rounds 1–4 out — this is the real call. The record is preserved verbatim in the private repo at packs/architect/rounds-1-4-record.md, on branch coach/architect-rounds-1-4-record. Rounds 1–4 existed nowhere else — the private pack only had round-5-record.md — so this move is preservation, not duplication. Reversible: revert this file and the content is unchanged in the private repo.
3. The correspondingPoId correction — a correctness change to doctrine, not an anonymisation one. It would be worth making even if this repo were private.

Not touched, and why

Six other tracked files mention HotWax: assets/moqui-data-feed.md, assets/maarg-data-manager.md, assets/moqui-integration-testing.md, assets/moqui-hemp-method.md, skills/moqui-data-feed/SKILL.md, skills/maarg-mdm/SKILL.md, plus agents/moqui-qa-technician.md, docs/ba-skill-spec.md, docs/prior-art-agent-teams.md and the five plugin manifests.

Those are a different category and I left them alone:

• the plugin manifests declare HotWax as the plugin author, so the name is on the tin already
• the skills and assets use co.hotwax.* as code identifiers in file:line citations — the author's own product namespace, which is what those docs are about

docs/ba-skill-spec.md is the one that looks like the same problem as this PR (project name ×4 in round headings, and the same engagement). It is BA-owned rather than architect-owned, so it is out of scope here. Flagging it as likely next.

Verification run

• identity scan over both files: clean
• rule inventory diffed before/after: 21 of 21 present, heading count unchanged
• correspondingPoId provenance: confirmed in upstream OFBiz source, cited above

---

Second file: docs/ba-skill-spec.md

Added after the first review. Same rule, same treatment, and the Coach owns this file too (packs/ba/PACK.md:27).

The leak was wider than the architect one. What was public:

Kind	Instance	Count
Client name	notnaked	2
Real retail brand	named in the D8 note as the client's real concession partner	1
Real person	a vendor-side employee's first name, same note	1
Project name	the same engagement as the architect spec	6
Audited PR	the client repo's PR number	1
Persona name	the round-1 role-play persona	1
Internal paths	working-copy paths	2
Package internals	question ids, R-rule ranges, story versions, evidence-entry ids, coverage tallies	many

D8 was written against its own evidence

D8 is the demo-naming lint. It says demo-facing artifacts are grep-audited so that no real people or brands appear.

Its own failure note named the real brand and the real person it was written about, sitting in this public repo for about a month.

The rule's example broke the rule, in the exact medium the rule is about. This is the same defect shape as the correspondingPoId claim above: the example that teaches a discipline is the place the discipline was not applied.

D8's rule text is unchanged. Only its evidence is generalised, and the file now states plainly that this happened, so the lesson survives the fix.

The discipline was already known

Rounds 3 and 5 carry the line "client identity never enters this repo" in their own headers, written 2026-07-11. So the rule was understood at the time. It was never applied backwards to rounds 1–2, or forwards to round 6 on 2026-07-17.

That suggests the gap is procedural rather than a one-off. Two things would close it, both outside this PR:

1. packs/ba/PACK.md has no public/private hygiene line. The architect pack has one and it is the reason that spec was easier to reason about. Worth adding.
2. G10 (rule-retrofit sweep) already exists for this exact failure mode, applied to engagement artifacts. It could be pointed at the specs themselves.

Same treatment, verified the same way

• Sections A–G were already clean. They are byte-identical, checked with diff.
• The round narratives moved to the private repo at packs/ba/rounds-1-6-record.md, verbatim, checked with diff. Rounds 1–6 existed nowhere else — that pack held only PACK.md.
• Failure evidence under each rule was generalised, not dropped.

Checked mechanically, before vs after:

Check	Before	After
Unique rules	57	57
## headings	14	14
Eval-case rows	5	5
Identity scan	12 hits	clean

Left alone, deliberately

"Anil as trainee" in the header. That is the author's own name, not client identity, and not mine to strip. Say the word if you want it out.

The two files can be accepted separately

Revert either file and the other still stands. The private record covers both and is also unmerged.