Extra exercises

Start after the main lab. Preserve it in a checkpoint and use a new branch.
Choose one; estimates are not timings from participant runs. Give the agent
only the objective and acceptance cases first. Let it inspect and choose
its approach/tools, then evaluate the plan. Hints are optional references
for after its own proposal; do not lead with an implementation hint.

1. Count the matches (about 10–15 minutes)
Objective: Show a result count beside the title filter.
Success: No query: all of this owner’s notes. A matching query: exactly the visible matches. No match: 0. Clear restores the full count and empties the input. Other owners’ notes never contribute.
After your own plan, optional hint: The loader already returns the filtered owner.notes array. Count notes, not the New Note link. Add a UI assertion and try all four states.

2. Sort without losing the filter (about 20–30 minutes)
Objective: Add an optional “Recently updated” sort while retaining the current default order.
Success: Keep the active title filter when changing sort. Sort only the displayed owner’s matches by updatedAt descending, with id as a deterministic tie-breaker. An unknown sort value falls back to the existing default. Clear removes the filter but retains the chosen sort.
After your own plan, optional hint: The Note model already has updatedAt. Put an explicit orderBy inside the owner’s notes relation only for the new sort. Test with fixed timestamps, tied timestamps, another owner and an invalid sort value.

3. Make the title limit visible (about 20–30 minutes)
Objective: Add a live title-length counter to the existing editor.
Success: Show the trimmed title’s length out of 100 on create and edit, including the initial value. Update while typing. Whitespace-only input still fails; 100 normalized characters pass and 101 fail on the server. Keep the existing error message and save flow.
After your own plan, optional hint: Read the existing Conform field metadata before adding duplicate state. Associate the counter with the input using aria-describedby. Do not announce every keystroke. Include a component test, a keyboard check and server boundary cases.

4. Test a forged delete (about 20–30 minutes)
Objective: Add a regression test for the existing note-delete action. Investigate the current behavior before changing it.
Success: Create synthetic Alice and Bob notes. Submit Bob’s actual note ID to the delete action while authenticated as Alice. Expect denial and assert Bob’s note still exists. A separate owner case must delete Alice’s own note. Keep public reading unchanged.
After your own plan, optional hint: Find the real action in $noteId.tsx and reuse the server-test authentication helpers. The test database is unseeded: give the fixture user a role with delete:note:own, without delete:note:any. Otherwise even the owner case will be denied. An assertion about a hidden button is insufficient. The existing protection may already pass: report that result rather than inventing a vulnerability.

5. Challenge another model
Follow COMPARE-MODELS.txt. Bring back both diffs, the observed scorecard and
a provisional recommendation.

PROMPT
Objective: deliver this chosen Epic Notes improvement:
[paste the user outcome and acceptance cases]

Constraints: use this existing VS Code project and approved tools.
Preserve ownership and title validation. No dependencies, migrations,
lockfile changes, installs, .env reads, commits or publishing.
Read AGENTS.md and keep normal permissions enabled.

Inspect the code and available capabilities before choosing an
approach or tools. Explain your choices, the smallest scope and
how to detect a wrong result. Ask about product decisions and stop.
After I approve, write and run a meaningful test, show that it detects
the missing behavior, then implement and execute the project gates.
Report actual commands, exit codes and gaps. Hand off for a fresh
Plan review and give me cases to evaluate in VS Code's preview.

After implementation, use REVIEW in PROMPTS.txt in a fresh Plan session.
Evaluate its proposal before approving checks. Evaluate behavior in VS Code
preview and explain your decision.

6. Map and check one security boundary
Use SECURITY-LAB.txt after the main lab. Map first, approve one bounded
regression, let the agent test/review and evaluate its evidence yourself.

ADDITIONAL OPTIONAL EXERCISES
Use the OPTIONAL prompt; acceptance details are in the blog.
- Dictate an objective with an approved existing voice tool; restate cases.
- Diagram the request path, citing real files/functions; verify one claim.
- Write a repo-grounded troubleshooting guide; follow it yourself from a fresh session.
- Plan semantic search against keyword search on synthetic examples. Pause
  before any model/service/dependency addition; an honest plan is enough.
- Investigate synthetic note-activity CSV data with known anomalies. Keep
  the source unchanged and show the calculation supporting each finding.
