diff --git a/.claude/agent-memory/critic/MEMORY.md b/.claude/agent-memory/critic/MEMORY.md new file mode 100644 index 0000000..edb4e56 --- /dev/null +++ b/.claude/agent-memory/critic/MEMORY.md @@ -0,0 +1,2 @@ +- [Release notes: unverified claims](risk_release_notes_unverified_claims.md) — CHANGELOG prose copied from commit subjects has shipped false counts and false "where it appears" claims. +- [Release workflow untestable pre-tag](risk_release_workflow_untestable.md) — release.yml/deploy-chrome.yml only run on a v*.*.* tag that publishes live; extract and run embedded scripts to review. diff --git a/.claude/agent-memory/critic/risk_release_notes_unverified_claims.md b/.claude/agent-memory/critic/risk_release_notes_unverified_claims.md new file mode 100644 index 0000000..97d92c9 --- /dev/null +++ b/.claude/agent-memory/critic/risk_release_notes_unverified_claims.md @@ -0,0 +1,16 @@ +--- +name: risk-release-notes-unverified-claims +description: Release-note/CHANGELOG entries in LexAI have been written from commit messages and feature-list intuition rather than verified against code — check counts and surface claims against source. +metadata: + type: project +--- + +CHANGELOG/release-note prose in this repo has shipped factual errors that came from trusting commit subjects instead of the code. + +Proven instances (2026-08-12 review of the v1.1.0 release prep): +- `CHANGELOG.md` 1.0.1 said Prompt Builder was "a new tab in the popup **and Options**", copying commit `acea99d`'s subject. `git show acea99d:entrypoints/options/Options.tsx` has zero prompt-builder references, and current `entrypoints/options/Options.tsx` still has none. +- `CHANGELOG.md` 1.1.0 said "12 named prompting patterns ... plus Auto" (implying 13). `PROMPT_PATTERNS` in `src/lib/actions.ts` has 12 entries *including* `auto` → 11 named + Auto. + +**Why:** release bodies are generated from `CHANGELOG.md` by `.gitea/workflows/release.yml`, so an unverified claim becomes a permanent public artifact on a tag push that also publishes live to the Chrome Web Store. + +**How to apply:** when reviewing any CHANGELOG/release-note change, verify every countable and every "where it appears" claim against the source file (grep the array, grep the entrypoint), and check the commit window with `git log ..` for user-visible features that were omitted. Do not accept a commit subject as evidence for a user-facing claim. Related: [[risk-release-workflow-untestable-pre-tag]]. diff --git a/.claude/agent-memory/critic/risk_release_workflow_untestable.md b/.claude/agent-memory/critic/risk_release_workflow_untestable.md new file mode 100644 index 0000000..d2b8443 --- /dev/null +++ b/.claude/agent-memory/critic/risk_release_workflow_untestable.md @@ -0,0 +1,15 @@ +--- +name: risk-release-workflow-untestable-pre-tag +description: .gitea/workflows/release.yml only runs on a v*.*.* tag that also publishes live to the Chrome Web Store — review it by extracting and executing the embedded script locally. +metadata: + type: project +--- + +`.gitea/workflows/release.yml` and `.gitea/workflows/deploy-chrome.yml` both trigger only on `push: tags: v*.*.*`, and the deploy workflow publishes live to the Chrome Web Store. A bug in either is first observed during a real release. + +**Why:** there is no dry-run path; CI never exercises these files on a normal push. + +**How to apply:** when a release workflow embeds a script in a heredoc inside a YAML block scalar, extract it and run it rather than reading it. Working recipe used on 2026-08-12: +`sed -n ',p' .gitea/workflows/release.yml | sed 's/^ //' > /brp.js` then run it with the relevant env var set, over the real `CHANGELOG.md`, for: the current tag, an older tag, the oldest tag (last-section / no-next-heading case), a tag with no section (fallback), and a prefix-collision tag such as `v1.1.0-beta`. This confirmed indentation stripping, heredoc termination, `VERSION="$VERSION" node ...` env passing, and JSON safety of `→`/em-dash/backticks in one pass. + +Also compare any zip/packaging edit against the known-good pattern at `.gitea/workflows/deploy-chrome.yml:47-57` — that pattern was itself a fix (commit `1fedaf4`) for a nested-directory zip that Chrome rejected. Related: [[risk-release-notes-unverified-claims]]. diff --git a/.claude/agent-memory/opus-orchestrator/MEMORY.md b/.claude/agent-memory/opus-orchestrator/MEMORY.md new file mode 100644 index 0000000..183a35e --- /dev/null +++ b/.claude/agent-memory/opus-orchestrator/MEMORY.md @@ -0,0 +1,4 @@ +# Opus orchestrator memory + +- [Release authority](project_release_authority.md) — owner does the load-unpacked check and owns the tag; a `v*.*.*` tag publishes live to the CWS with no approval gate. +- [Owner approval style](feedback_owner_approval_style.md) — "proceed" means apply the plan's recommended defaults; it never authorizes a step the plan parked. diff --git a/.claude/agent-memory/opus-orchestrator/feedback_owner_approval_style.md b/.claude/agent-memory/opus-orchestrator/feedback_owner_approval_style.md new file mode 100644 index 0000000..3f0d81b --- /dev/null +++ b/.claude/agent-memory/opus-orchestrator/feedback_owner_approval_style.md @@ -0,0 +1,12 @@ +--- +name: feedback-owner-approval-style +description: Owner approves by saying "proceed" without answering the plan's open questions — apply the recommended defaults and keep going, but still stop at irreversible external actions +metadata: + type: feedback +--- + +When a plan ends with open decisions and the owner replies "proceed" rather than answering them, treat the recommended option for each as chosen and execute — do not re-ask. + +**Why:** on the v1.1.0 release (2026-08-12) the plan posed three questions (version number, how far to go, whether to include an adjacent fix); the owner answered "now proceed execution". Re-asking would have stalled work he had already delegated by choosing the recommendation. + +**How to apply:** state the applied defaults in the orchestration record so the assumption is visible and correctable, then run. The exception is any action the plan itself parked as owner-authorized — publishing, tagging a release, destructive or external state changes: "proceed" on the plan is not authorization for the step the plan explicitly deferred. See [[project-release-authority]]. diff --git a/.claude/agent-memory/opus-orchestrator/project_release_authority.md b/.claude/agent-memory/opus-orchestrator/project_release_authority.md new file mode 100644 index 0000000..ccc95ee --- /dev/null +++ b/.claude/agent-memory/opus-orchestrator/project_release_authority.md @@ -0,0 +1,12 @@ +--- +name: project-release-authority +description: LexAI releases — the owner tests load-unpacked personally and holds the tag; a v*.*.* tag publishes live to the Chrome Web Store with no manual approval step +metadata: + type: project +--- + +The owner does the real-page (load-unpacked) verification himself and reports it back; agents should treat that as the DOM/selection acceptance evidence rather than trying to reproduce it. The `v*.*.*` tag is his to fire. + +**Why:** pushing a `v*.*.*` tag runs `deploy-chrome.yml`, which uploads *and publishes* to the Chrome Web Store in the same run — there is no draft/approval gate, and a published CWS version cannot be unpublished in place (only superseded by a higher version). Tags v1.0.1 and v1.0.2 were never created on the remote even though those versions exist in `package.json` history, so remote tag state must be read (`git ls-remote --tags origin`) rather than inferred from `package.json`. + +**How to apply:** take a release through bump → gates → merge to `main` → stop. Park the tag as an owner decision in `docs/PROGRESS.md`. Never create a tag without an explicit, specific go. See [[feedback-owner-approval-style]].