Skip to content

Split the requirements package by audience - #25

Open
patelanil wants to merge 4 commits into
mainfrom
docs/two-audience-deliverables
Open

Split the requirements package by audience#25
patelanil wants to merge 4 commits into
mainfrom
docs/two-audience-deliverables

Conversation

@patelanil

Copy link
Copy Markdown
Collaborator

Two commits. Please read the note on the first one.

Commit 1: coaching harvest rounds 5 to 8

This work is the sponsor's, not mine. It was sitting uncommitted in the
working tree. The sponsor confirmed it was theirs and safe to build on, so it
is committed here as its own commit rather than being buried under my change.

Architect rules on native graph I/O, MDM in the native-first ladder, entity
masters for a whole graph, and a revision sweep discipline. A business analyst
rule that superseding a recorded Expert-User answer requires a read-back. A QA
rule that the declared scope is itself a claim. Plus the new
moqui-master-entity skill and a version bump to 0.13.0.

If any of that is not ready to merge, split this branch.

Commit 2: the audience split

The BA produces a record. Every sentence carries its source, its weight and
an identifier. That is right for provenance and unreadable for a person who
has to build from it.

The package now splits:

docs/<feature>/README.md            one page, says what to read
docs/<feature>/developer-guide.md   plain English, for the builder
docs/<feature>/record/              every artifact the BA produces

The guide is written before the engagement is called finished, not when
someone asks for it.

QA's story gate gains a reader check. A package that passes provenance, lint,
completeness and question quality, and that nobody can read, has not been
handed over. That is a finding, not a nicety.

Why

A live engagement produced a thirteen-file requirements package. The sponsor
read it and said it felt technical and cryptic, like a research paper.

Only one of the thirteen was for them. It did not exist until they asked for
it, near the end. Every other file had passed the story gate.

Related

…12.0

Returns/refunds record-bound engagement (2026-07-23, sponsor-approved
harvest). Round 7 log added to ba-skill-spec with the two new rules,
five keeper patterns (incl. [SPONSOR]/[KB] provenance grades), and a
fixture-hygiene finding (EC2/EC3 canonical inputs not stored). Both
rules folded into the agent definition's Rules section.

Regression replay on the upgraded definition: EC1 PASS - both traps
avoided (sync requirement survived the design cut per B1a; 'nightly'
demoted to hint, freshness became the open question). EC2/EC3 not
replayed: no stored canonical input (finding recorded); EC4/EC5
full-engagement fixtures deferred - the delta is two additive rules
touching neither elicitation nor gap/overlap behavior.
moqui-coding-assistant stays domain-neutral: business-domain information
(client, feature domain, artifact names) moved out of the round log to
the coach repo's private fixtures, which the log now points to. The two
rules, keeper patterns, and fixture-hygiene finding are unchanged - they
were always craft, not domain.
Sponsor-approved rules from coaching rounds 5 to 8, dated 2026-07-24.

Architect: native graph I/O and MDM placed in the native-first ladder;
entity masters for a whole graph; a revision sweep discipline.

Business analyst: superseding a recorded Expert-User answer requires a
read-back. A ruling can redirect delivery. It cannot retroactively change
what the Expert User said.

QA technician: the declared scope is itself a claim. Certify the boundary
before certifying the content.

New skill: moqui-master-entity, with its asset.

Version to 0.13.0.

Committed by Claude on the sponsor's instruction. The work is the
sponsor's; it was uncommitted in the working tree.
The BA produces a record. Every sentence carries its source, its weight
and an identifier. That is right for provenance and unreadable for a
person who has to build from it.

The package now splits:

  docs/<feature>/README.md            one page, says what to read
  docs/<feature>/developer-guide.md   plain English, for the builder
  docs/<feature>/record/              every artifact the BA produces

The guide is written before the engagement is called finished, not when
someone asks for it.

QA's story gate gains a reader check. A package that passes provenance,
lint, completeness and question quality, and that nobody can read, has
not been handed over. That is a finding.

This came out of a live engagement. The sponsor read a thirteen-file
package and said it felt technical and cryptic, like a research paper.
Only one file was for them, and it did not exist until they asked.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant