Epic Notes: prepare for an incident

Do this after the main lab, on a new branch. Stay in VS Code.
Use the existing OpenCode/model setup. No external targets or scans.

1. /new, Plan. Paste:

Objective: identify the three most important security boundaries in
this local Epic Notes app and propose one useful regression check.
Success: each finding cites an actual file/function, the protected
operation, who should be allowed, and evidence that could prove it wrong.

Constraints: read-only planning inside this approved VS Code project.
Use synthetic data only. No .env/secrets, external directories, installs,
network scans, public targets, dependency upgrades, configuration edits,
commits or deployment. Public note reading is intended behavior.
Existing AGENTS.md rules, permissions and project gates still apply.

Inspect the repository and available capabilities before choosing tools.
Explain what is confirmed, what is only a hypothesis, and what you cannot
verify. Choose your approach, justify it and stop after the plan.
Do not invent a vulnerability because a security exercise asks for one.

2. Evaluate the plan. Choose one boundary and its acceptance cases.
Start a fresh Plan session and paste:

Objective: demonstrate the approved authorization boundary:
[paste the selected operation and expected owner/non-owner outcomes].
Success: a valid authorized action still works; a direct unauthorized
request is denied; the protected record stays unchanged.

Constraints: local Epic Notes and synthetic fixtures only. Preserve the
existing product behavior and permissions. No .env/secrets, installs,
network scans, external targets, global configuration, dependency or
lockfile changes, authentication redesign, commits or deployment.
Do not weaken or skip existing checks. No parallel writers.

Inspect the relevant code and tests. Choose the test tools and approach
already available in the project; explain the proposed scope and stop.
After I approve, write or reuse a meaningful regression, execute it and
the documented project gates, and report actual commands, exit codes and
gaps. Existing correct behavior may already pass: report that honestly.
If a defect appears, stop with a proposed fix for separate approval.
Then hand off to the tutorial's fresh Plan review. Give me acceptance
cases to evaluate in VS Code's integrated browser.

3. Approve a bounded plan before switching to Build. Let the agent
write/reuse and execute the test and project gates. A passing existing
protection is useful evidence. If a defect is found, approve a fix separately.

4. Use the fresh-review prompt in PROMPTS.txt, then evaluate the cases
in VS Code's integrated browser. Read the blog #security-lab for reference
code and checkpoints. Reference after the completed main lab:

npm test -- --run --maxWorkers=2 'app/routes/users/$username/notes/+shared/note-editor.server.test.tsx'


At work: inventory/version owner, exposure, least privilege, useful logs,
tested backups and an incident contact. Never paste real secrets into chat.
