Repository navigation
Which conventions of the existing e2e suite become tenant conventions, and who owns its directory? #543
Description
Question
Agree with the author of the existing e2e suite which of its conventions become tenant conventions, and who owns the suite directory once /build writes tests into it.
The suite is documented and in review. Its README states a naming contract, a fixtures import point, a Page Object layer, a tagging rule and a device and locale matrix. For each convention, record whether it stays as written, and by which transport it reaches /build: a suite check, an instructed read, or a declared skill.
HITL: the author speaks for the suite. The agent prepares the list and records the answers.
Activity
orioltf commentedon Sep 23, 2026
Constraint from a closed decision
Does v1 require resettable test data, or do generated tests own their data? decided that data provisioning belongs to the Consumer's suite author. Data provisioning is the code that creates or restores the data e2e tests depend on. In a Playwright Pack it takes the form of the setup and teardown projects.
/buildnever writes it in v1, and by default e2e tests are read-only.For this ticket, two questions for the suite's author:
orioltf commentedon Sep 29, 2026
Constraint from #547
Decided with the maintainer on 2026-09-29, while resolving #547.
Wherever this ticket puts the e2e conventions,
/pr-reviewmust be able to read them. Its Standards axis gathers onlyCLAUDE.md,AGENTS.md,CONTRIBUTING.mdandCODING_STANDARDS.md, in step 3 of thereviewnode inunic-dlc-pr-review.yaml. So the conventions either live in one of those files, or one of them points at the file that holds them.The second Consumer keeps the conventions of its existing generate-then-review chains under
.claude/skills/<name>/references/. As things stand, the Standards axis would not read e2e conventions kept there.Whether the model follows a pointer from
CLAUDE.mdorAGENTS.mdto another file is unmeasured. The general fix, where a Practice Pack declares its standards, belongs to #520's grilling.orioltf commentedon Sep 29, 2026
Constraint from What baseline does the second Consumer measure before the first run?
Every generated test must name the ID of the acceptance criterion it covers. The Consumer counts the share of criteria with an automated test in CI from that ID, so without it the metric cannot be counted.
#548 fixes only that the ID is present. This ticket decides how it is written, for example in the test title or as a Playwright annotation, and whether the existing suite's naming contract already has a place for it.
orioltf commentedon Oct 1, 2026
Answers from the suite's author, 2026-10-01
The maintainer sent the suite's author one proposal per convention, and the author answered each one. Answers settle this ticket's question.
Where the conventions live
e2e/README.md./buildreads them there, so each one reaches/buildas an instructed read. The suite's config and pipeline still check the file suffixes and the device and locale matrix.CLAUDE.mdgets one line that points ate2e/README.md. The constraint from #547 says/pr-review's Standards axis must be able to reach the conventions, and that axis readsCLAUDE.md. TodayCLAUDE.mddoes not mention the e2e suite. The author agreed. The line is a change in the Consumer's repository, not in this one. Whether the model follows such a pointer is still unmeasured (Does /pr-review sit beside or replace the second Consumer's existing reviewer? #547).Who owns the suite directory
e2e/gets a human review. The author wants that kept./buildwrites no data provisioning in v1. If a later version needs it, the author is open to it./buildwrites only undere2e/tests/<feature>/ande2e/pages/, plus one fixture entry for each new Page Object. The author owns everything else ine2e/. The author agreed.Conventions that change
@smoketests first, and runs@featuretests minus@smokein later stages, so no test runs twice. The README shows only part of this today, and the author will fix it. So a generated acceptance test carries@featureand an environment tag, and never@smoke.cross-envin the next pull request. Until then,/buildcannot run the suite on macOS or Linux.The criterion ID
#548 requires every generated test to name its criterion ID. The author's answer is about where criteria live. Ideally a tracker item holds the test automation documentation: the scenario and the bugs linked to it. Not every project has one. The author suggested that an agent could create those tracker items too.
apps/claude-code/unic-archon-dlc/CONTEXT.md(Acceptance Slice) stands: the ID goes in the test title.Coverage
The question of which pipeline run counts the criteria with an automated test did not land. The e2e pipeline has no trigger yet. The count belongs to the Consumer's QA Baseline work from #548, which the Consumer owns.
What is left
Nothing for this map. The author agreed to the
CLAUDE.mdpointer and the split ofe2e/in a follow-up answer the same day. The tag fix,cross-env, the clean-up and theCLAUDE.mdline are work in the Consumer's repository, and none of them is a decision for this map. The criterion ID format stays at its default.