UX Testing Learnings — Institutional Memory For Testing

When to Use

• Before testing any UX flow — search for prior learnings to avoid repeating known failures
• After discovering anything during testing — log it so future agents benefit
• When debugging a test failure — check if another agent already found the root cause

Where this lives

If a memory-search command is configured (/alignment-harness:harness-setup, or the project's own institutional-memory tool), use it, filtered or tagged for testing.

Otherwise, use the harness's local store — a JSON-lines file at alignment-harness records ux-testing-learnings/log.jsonl. No server, no key, no separate database:

Search:

DIR=$(alignment-harness records ux-testing-learnings)
grep -i "login" "$DIR/log.jsonl" 2>/dev/null

Log:

DIR=$(alignment-harness records ux-testing-learnings)
echo '{"title":"Login flow fails when cookie expired","lesson":"Must clear cookie before retry, not just refresh token","outcome":"loss","severity":"high","testFlow":"login","tags":["login","cookie","auth"],"at":"<ISO timestamp>"}' >> "$DIR/log.jsonl"

If the project has its own admin UI or dashboard for reviewing testing learnings, that's where a human reviews them; otherwise, the log file itself is the review surface — tell the person its path.

Say plainly when the memory is stale or empty

• Empty store: "I don't have any testing history yet for this — I'll log what I find so the next test on this flow doesn't start from zero." Never invent a plausible-sounding prior finding to fill the gap.
• Stale store: if the newest entry you find is more than a few weeks old, say so — "this hasn't been updated in N days, treating it as historical, not current" — rather than presenting old findings as if they reflect the current state of the code.

Outcome Types

Outcome	Emoji	When to use
win	✅	Confirmed a flow works correctly
loss	❌	Found a bug or regression
pattern	🔄	Recurring observation (not a bug, not a win)
workaround	🔧	Found a way around a limitation
blocker	🚫	Cannot proceed — needs human or code fix

Agent Workflow

1. Before testing: search for the flow you're about to test (memory-search command if configured, otherwise grep the local log)
2. Read learnings: Apply known workarounds, skip known blockers — but check dates; don't treat stale findings as current
3. Test the flow: Navigate, interact, verify
4. Log what you find: append to the local log (or the project's own store)
5. Tag consistently: Use flow names (login, checkout, onboarding) and component names as tags