mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 4.7
7d7301614d
Add cli/contributing/changelog/archive: a CLI that trims CHANGELOG.md
to the last N entries (default 7) and writes every older release to
its own file under docs/changelog/ named <padded-semver>-<date>.md
(7.0.0 → 007.000.000-2026-05-08.md). The padded form makes a directory
listing already chronological, and the index in CHANGELOG.md is
rebuilt from the archive directory listing on every run, so it never
drifts away from what is on disk. The tool is idempotent and never
overwrites an existing archive file.
Run the migration once to split the 44-entry CHANGELOG.md into 7
inline entries plus 37 archived per-release files, with the index at
the bottom of CHANGELOG.md linking each archive in descending order.
Add docs/contributing/actions/release.md as the contributor-facing
release procedure (versioning, active window vs. archive, cutting a
release end-to-end, CI hand-off on tag push) and add a docs README
under docs/changelog/ that explains the archive directory layout and
filename schema. Cross-link release.md from pipeline.md and add
"releases" to the actions/ scope description.
Documentation cleanup pass on every page touched in the previous
mapping refactor:
- Remove "is the SPOT for X" / "Single Point of Truth" self-labels
across docs/contributing/, docs/agents/, and docs/changelog/. The
rule in documentation.md forbids self-declared SPOT status; status
is conferred by readers cross-linking, not by the page asserting
it. Rephrase to descriptive phrasing ("This page covers X",
"describes X", "lists X") throughout.
- Drop the orphaned docs/contributing/tools/actions.md duplicate
(101 lines paralleling tools/github/actions/workflows.md, with no
inbound links).
- Fix em-dashes used as thought breaks in dockerfile.md, origin.md,
agents/style.css.md, and suppression.md per documentation.md.
- Unwrap soft-wrapped sentences in iam/common.md, iam/ldap.md,
iam/oidc.md, image/origin.md, requirements.md, and dockerfile.md
so each logical line carries one full sentence.
Add a unit test for the archive CLI under
tests/unit/cli/contributing/changelog/archive/test_main.py covering
_pad_version, _split_into_entries, idempotency, dry-run, no-overwrite
of existing archives, and the multi-run index rebuild.
Quote `# noqa:` in CHANGELOG.md prose with backticks so the
noqa-only-ruff-codes lint does not parse "for" as a non-ruff code.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.6 KiB
2.6 KiB
playwright.spec.js agent procedure
This page covers the agent procedure when generating or updating a role-local playwright.spec.js. It does NOT restate what the file must contain. Those rules are authoritative in Contributing playwright.spec.js and MUST be consulted before every task.
For framework and runner mechanics, see Playwright Tests.
For the matching environment contract, see Role playwright.env.j2.
Procedure
- Read the contributor SPOT and treat every MUST there as a non-negotiable acceptance criterion for the generated spec.
- Inspect the role's
meta/services.yml(and the matchingmeta/server.yml/meta/rbac.yml) anddefaults/main.ymlto determine the supported entry point (dashboard vs. direct app), enabled integrations (OIDC, LDAP, messaging, etc.), and active personas. - Read or author the role's
templates/playwright.env.j2first and keep every variable name aligned with the generated spec. - Draft scenarios from the live running stack, not from assumptions. Use Playwright codegen or
playwright-recorder(see the framework SPOT) as a starting point when the DOM structure is unknown. - Deploy the role and run the spec inside the shared
test-e2e-playwrightrunner until every MUST in the contributor SPOT passes and the browser console is free of unhandled errors. - When the change was triggered by an update to role-local
style.cssorjavascript.js, verify the new visible behavior is covered before reporting the task complete.
Live Review
Before reporting the task complete, you MUST verify the spec against a running stack, not against file contents alone. Static file review misses navigation and auth bugs that only surface in the browser.
- You MUST drive the scenarios through a real browser session against the deployed role. A green local file-lint does not satisfy this step.
- You MUST inspect the start page AND the login page of the role as part of the end-to-end run. These two pages surface most navigation, authentication, and first-load regressions that later assertions would only catch indirectly.
- You MUST open the browser console during runs that depend on injected JavaScript and confirm it is free of unhandled errors before reporting success.
Reporting
- Report which MUSTs in the contributor SPOT were verified end to end and which were covered only by a static check, if any.
- Reference the deploy log path when the run surfaced any anomaly the reviewer should see.