refactor(runtime): replace unicode dashes in prompt strings
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
This commit is contained in:
YeonGyu-Kim
@@ -51,8 +51,8 @@ Assume the work is broken until YOU prove otherwise.
|
||||
|
||||
Do NOT run tests yet. Read the code FIRST so you know what you're testing.
|
||||
|
||||
1. \`Bash("git diff --stat")\` — see exactly which files changed. Any file outside expected scope = scope creep.
|
||||
2. \`Read\` EVERY changed file — no exceptions, no skimming.
|
||||
1. \`Bash("git diff --stat")\` - see exactly which files changed. Any file outside expected scope = scope creep.
|
||||
2. \`Read\` EVERY changed file - no exceptions, no skimming.
|
||||
3. For EACH file, critically ask:
|
||||
- Does this code ACTUALLY do what the task required? (Re-read the task, compare line by line)
|
||||
- Any stubs, TODOs, placeholders, hardcoded values? (\`Grep\` for TODO, FIXME, HACK, xxx)
|
||||
@@ -60,46 +60,46 @@ Do NOT run tests yet. Read the code FIRST so you know what you're testing.
|
||||
- Anti-patterns? (\`Grep\` for \`as any\`, \`@ts-ignore\`, empty catch, console.log in changed files)
|
||||
- Scope creep? Did the subagent touch things or add features NOT in the task spec?
|
||||
4. Cross-check every claim:
|
||||
- Said "Updated X" — READ X. Actually updated, or just superficially touched?
|
||||
- Said "Added tests" — READ the tests. Do they test REAL behavior or just \`expect(true).toBe(true)\`?
|
||||
- Said "Follows patterns" — OPEN a reference file. Does it ACTUALLY match?
|
||||
- Said "Updated X" - READ X. Actually updated, or just superficially touched?
|
||||
- Said "Added tests" - READ the tests. Do they test REAL behavior or just \`expect(true).toBe(true)\`?
|
||||
- Said "Follows patterns" - OPEN a reference file. Does it ACTUALLY match?
|
||||
|
||||
**If you cannot explain what every changed line does, you have NOT reviewed it.**
|
||||
|
||||
**PHASE 2: RUN AUTOMATED CHECKS (targeted, then broad)**
|
||||
|
||||
Now that you understand the code, verify mechanically:
|
||||
1. \`lsp_diagnostics\` on EACH changed file — ZERO new errors
|
||||
1. \`lsp_diagnostics\` on EACH changed file - ZERO new errors
|
||||
2. Run tests for changed modules FIRST, then full suite
|
||||
3. Build/typecheck — exit 0
|
||||
3. Build/typecheck - exit 0
|
||||
|
||||
If Phase 1 found issues but Phase 2 passes: Phase 2 is WRONG. The code has bugs that tests don't cover. Fix the code.
|
||||
|
||||
**PHASE 3: HANDS-ON QA — ACTUALLY RUN IT (MANDATORY for user-facing changes)**
|
||||
**PHASE 3: HANDS-ON QA - ACTUALLY RUN IT (MANDATORY for user-facing changes)**
|
||||
|
||||
Tests and linters CANNOT catch: visual bugs, wrong CLI output, broken user flows, API response shape issues.
|
||||
|
||||
**If this task produced anything a user would SEE or INTERACT with, you MUST launch it and verify yourself.**
|
||||
|
||||
- **Frontend/UI**: \`/playwright\` skill — load the page, click through the flow, check console. Verify: page loads, interactions work, console clean, responsive.
|
||||
- **TUI/CLI**: \`interactive_bash\` — run the command, try good input, try bad input, try --help. Verify: command runs, output correct, error messages helpful, edge inputs handled.
|
||||
- **API/Backend**: \`Bash\` with curl — hit the endpoint, check response body, send malformed input. Verify: returns 200, body correct, error cases return proper errors.
|
||||
- **Frontend/UI**: \`/playwright\` skill - load the page, click through the flow, check console. Verify: page loads, interactions work, console clean, responsive.
|
||||
- **TUI/CLI**: \`interactive_bash\` - run the command, try good input, try bad input, try --help. Verify: command runs, output correct, error messages helpful, edge inputs handled.
|
||||
- **API/Backend**: \`Bash\` with curl - hit the endpoint, check response body, send malformed input. Verify: returns 200, body correct, error cases return proper errors.
|
||||
- **Config/Build**: Actually start the service or import the config. Verify: loads without error, backward compatible.
|
||||
|
||||
This is NOT optional "if applicable". If the deliverable is user-facing and you did not run it, you are shipping untested work.
|
||||
|
||||
**PHASE 4: GATE DECISION — Should you proceed to the next task?**
|
||||
**PHASE 4: GATE DECISION - Should you proceed to the next task?**
|
||||
|
||||
Answer honestly:
|
||||
1. Can I explain what EVERY changed line does? (If no — back to Phase 1)
|
||||
2. Did I SEE it work with my own eyes? (If user-facing and no — back to Phase 3)
|
||||
3. Am I confident nothing existing is broken? (If no — run broader tests)
|
||||
1. Can I explain what EVERY changed line does? (If no - back to Phase 1)
|
||||
2. Did I SEE it work with my own eyes? (If user-facing and no - back to Phase 3)
|
||||
3. Am I confident nothing existing is broken? (If no - run broader tests)
|
||||
|
||||
ALL three must be YES. "Probably" = NO. "I think so" = NO. Investigate until CERTAIN.
|
||||
|
||||
- **All 3 YES** — Proceed: mark task complete, move to next.
|
||||
- **Any NO** — Reject: resume session with \`session_id\`, fix the specific issue.
|
||||
- **Unsure** — Reject: "unsure" = "no". Investigate until you have a definitive answer.
|
||||
- **All 3 YES** - Proceed: mark task complete, move to next.
|
||||
- **Any NO** - Reject: resume session with \`session_id\`, fix the specific issue.
|
||||
- **Unsure** - Reject: "unsure" = "no". Investigate until you have a definitive answer.
|
||||
|
||||
**DO NOT proceed to the next task until all 4 phases are complete and the gate passes.**`
|
||||
|
||||
@@ -121,12 +121,12 @@ Thinking "it looks correct" is NOT verification. Running \`lsp_diagnostics\` IS.
|
||||
|
||||
---
|
||||
|
||||
**PHASE 1: READ THE CODE FIRST (DO NOT SKIP — DO NOT RUN TESTS YET)**
|
||||
**PHASE 1: READ THE CODE FIRST (DO NOT SKIP - DO NOT RUN TESTS YET)**
|
||||
|
||||
Read the code FIRST so you know what you're testing.
|
||||
|
||||
1. \`Bash("git diff --stat")\` — see exactly which files changed.
|
||||
2. \`Read\` EVERY changed file — no exceptions, no skimming.
|
||||
1. \`Bash("git diff --stat")\` - see exactly which files changed.
|
||||
2. \`Read\` EVERY changed file - no exceptions, no skimming.
|
||||
3. For EACH file:
|
||||
- Does this code ACTUALLY do what the task required? RE-READ the task spec.
|
||||
- Any stubs, TODOs, placeholders? \`Grep\` for TODO, FIXME, HACK, xxx
|
||||
@@ -138,9 +138,9 @@ Read the code FIRST so you know what you're testing.
|
||||
|
||||
**PHASE 2: RUN AUTOMATED CHECKS**
|
||||
|
||||
1. \`lsp_diagnostics\` on EACH changed file — ZERO new errors. ACTUALLY RUN THIS.
|
||||
1. \`lsp_diagnostics\` on EACH changed file - ZERO new errors. ACTUALLY RUN THIS.
|
||||
2. Run tests for changed modules, then full suite. ACTUALLY RUN THESE.
|
||||
3. Build/typecheck — exit 0.
|
||||
3. Build/typecheck - exit 0.
|
||||
|
||||
If Phase 1 found issues but Phase 2 passes: Phase 2 is WRONG. Fix the code.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ function buildReuseHint(sessionId: string): string {
|
||||
|
||||
export function buildCompletionGate(planName: string, sessionId: string): string {
|
||||
return `
|
||||
**COMPLETION GATE — DO NOT PROCEED UNTIL THIS IS DONE**
|
||||
**COMPLETION GATE - DO NOT PROCEED UNTIL THIS IS DONE**
|
||||
|
||||
Your completion will NOT be recorded until you complete ALL of the following:
|
||||
|
||||
@@ -90,7 +90,7 @@ The subagent was instructed to record findings in notepad files. Read them NOW:
|
||||
\`\`\`
|
||||
Glob(".sisyphus/notepads/${planName}/*.md")
|
||||
\`\`\`
|
||||
Then \`Read\` each file found — especially:
|
||||
Then \`Read\` each file found - especially:
|
||||
- **learnings.md**: Patterns, conventions, successful approaches discovered
|
||||
- **issues.md**: Problems, blockers, gotchas encountered during work
|
||||
- **problems.md**: Unresolved issues, technical debt flagged
|
||||
@@ -100,7 +100,7 @@ Then \`Read\` each file found — especially:
|
||||
- Adjust your plan if blockers were discovered
|
||||
- Propagate learnings to subsequent subagents
|
||||
|
||||
**STEP 6: CHECK BOULDER STATE DIRECTLY (EVERY TIME — NO EXCEPTIONS)**
|
||||
**STEP 6: CHECK BOULDER STATE DIRECTLY (EVERY TIME - NO EXCEPTIONS)**
|
||||
|
||||
Do NOT rely on cached progress. Read the plan file NOW:
|
||||
\`\`\`
|
||||
@@ -166,7 +166,7 @@ export function buildStandaloneVerificationReminder(sessionId: string): string {
|
||||
|
||||
${buildVerificationReminder(sessionId)}
|
||||
|
||||
**STEP 5: CHECK YOUR PROGRESS DIRECTLY (EVERY TIME — NO EXCEPTIONS)**
|
||||
**STEP 5: CHECK YOUR PROGRESS DIRECTLY (EVERY TIME - NO EXCEPTIONS)**
|
||||
|
||||
Do NOT rely on memory or cached state. Run \`todoread\` NOW to see exact current state.
|
||||
Count pending vs completed tasks. This is your ground truth for what comes next.
|
||||
|
||||
@@ -44,8 +44,8 @@ export const ULTRAWORK_DEFAULT_MESSAGE = `<ultrawork-mode>
|
||||
|
||||
**WHEN IN DOUBT:**
|
||||
\`\`\`
|
||||
task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK DESCRIPTION] and need to understand [SPECIFIC KNOWLEDGE GAP]. Find [X] patterns in the codebase — show file paths, implementation approach, and conventions used. I'll use this to [HOW RESULTS WILL BE USED]. Focus on src/ directories, skip test files unless test patterns are specifically needed. Return concrete file paths with brief descriptions of what each file does.", run_in_background=true)
|
||||
task(subagent_type="librarian", load_skills=[], prompt="I'm working with [LIBRARY/TECHNOLOGY] and need [SPECIFIC INFORMATION]. Find official documentation and production-quality examples for [Y] — specifically: API reference, configuration options, recommended patterns, and common pitfalls. Skip beginner tutorials. I'll use this to [DECISION THIS WILL INFORM].", run_in_background=true)
|
||||
task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK DESCRIPTION] and need to understand [SPECIFIC KNOWLEDGE GAP]. Find [X] patterns in the codebase - show file paths, implementation approach, and conventions used. I'll use this to [HOW RESULTS WILL BE USED]. Focus on src/ directories, skip test files unless test patterns are specifically needed. Return concrete file paths with brief descriptions of what each file does.", run_in_background=true)
|
||||
task(subagent_type="librarian", load_skills=[], prompt="I'm working with [LIBRARY/TECHNOLOGY] and need [SPECIFIC INFORMATION]. Find official documentation and production-quality examples for [Y] - specifically: API reference, configuration options, recommended patterns, and common pitfalls. Skip beginner tutorials. I'll use this to [DECISION THIS WILL INFORM].", run_in_background=true)
|
||||
task(subagent_type="oracle", load_skills=[], prompt="I need architectural review of my approach to [TASK]. Here's my plan: [DESCRIBE PLAN WITH SPECIFIC FILES AND CHANGES]. My concerns are: [LIST SPECIFIC UNCERTAINTIES]. Please evaluate: correctness of approach, potential issues I'm missing, and whether a better alternative exists.", run_in_background=false)
|
||||
\`\`\`
|
||||
|
||||
@@ -202,7 +202,7 @@ BEFORE writing ANY code, you MUST define:
|
||||
| **Observable** | What can be measured/seen | "Console shows 'success', no errors" |
|
||||
| **Pass/Fail** | Binary, no ambiguity | "Returns 200 OK" not "should work" |
|
||||
|
||||
Write these criteria explicitly. **Record them in your TODO/Task items.** Each task MUST include a "QA: [how to verify]" field. These criteria are your CONTRACT — work toward them, verify against them.
|
||||
Write these criteria explicitly. **Record them in your TODO/Task items.** Each task MUST include a "QA: [how to verify]" field. These criteria are your CONTRACT - work toward them, verify against them.
|
||||
|
||||
### Test Plan Template (MANDATORY for non-trivial tasks)
|
||||
|
||||
@@ -233,7 +233,7 @@ Write these criteria explicitly. **Record them in your TODO/Task items.** Each t
|
||||
|
||||
**YOUR FAILURE MODE**: You finish coding, run lsp_diagnostics, and declare "done" without actually TESTING the feature. lsp_diagnostics catches type errors, NOT functional bugs. Your work is NOT verified until you MANUALLY test it.
|
||||
|
||||
**WHAT MANUAL QA MEANS — execute ALL that apply:**
|
||||
**WHAT MANUAL QA MEANS - execute ALL that apply:**
|
||||
|
||||
| If your change... | YOU MUST... |
|
||||
|---|---|
|
||||
@@ -245,10 +245,10 @@ Write these criteria explicitly. **Record them in your TODO/Task items.** Each t
|
||||
| Modifies config handling | Load the config. Verify it parses correctly. |
|
||||
|
||||
**UNACCEPTABLE QA CLAIMS:**
|
||||
- "This should work" — RUN IT.
|
||||
- "The types check out" — Types don't catch logic bugs. RUN IT.
|
||||
- "lsp_diagnostics is clean" — That's a TYPE check, not a FUNCTIONAL check. RUN IT.
|
||||
- "Tests pass" — Tests cover known cases. Does the ACTUAL FEATURE work as the user expects? RUN IT.
|
||||
- "This should work" - RUN IT.
|
||||
- "The types check out" - Types don't catch logic bugs. RUN IT.
|
||||
- "lsp_diagnostics is clean" - That's a TYPE check, not a FUNCTIONAL check. RUN IT.
|
||||
- "Tests pass" - Tests cover known cases. Does the ACTUAL FEATURE work as the user expects? RUN IT.
|
||||
|
||||
**You have Bash, you have tools. There is ZERO excuse for not running manual QA.**
|
||||
**Manual QA is the FINAL gate before reporting completion. Skip it and your work is INCOMPLETE.**
|
||||
|
||||
@@ -21,12 +21,12 @@ export const ULTRAWORK_GEMINI_MESSAGE = `<ultrawork-mode>
|
||||
[CODE RED] Maximum precision required. Ultrathink before acting.
|
||||
|
||||
<GEMINI_INTENT_GATE>
|
||||
## STEP 0: CLASSIFY INTENT — THIS IS NOT OPTIONAL
|
||||
## STEP 0: CLASSIFY INTENT - THIS IS NOT OPTIONAL
|
||||
|
||||
**Before ANY tool call, exploration, or action, you MUST output:**
|
||||
|
||||
\`\`\`
|
||||
I detect [TYPE] intent — [REASON].
|
||||
I detect [TYPE] intent - [REASON].
|
||||
My approach: [ROUTING DECISION].
|
||||
\`\`\`
|
||||
|
||||
@@ -81,8 +81,8 @@ Where TYPE is one of: research | implementation | investigation | evaluation | f
|
||||
|
||||
**WHEN IN DOUBT:**
|
||||
\`\`\`
|
||||
task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK DESCRIPTION] and need to understand [SPECIFIC KNOWLEDGE GAP]. Find [X] patterns in the codebase — show file paths, implementation approach, and conventions used. I'll use this to [HOW RESULTS WILL BE USED]. Focus on src/ directories, skip test files unless test patterns are specifically needed. Return concrete file paths with brief descriptions of what each file does.", run_in_background=true)
|
||||
task(subagent_type="librarian", load_skills=[], prompt="I'm working with [LIBRARY/TECHNOLOGY] and need [SPECIFIC INFORMATION]. Find official documentation and production-quality examples for [Y] — specifically: API reference, configuration options, recommended patterns, and common pitfalls. Skip beginner tutorials. I'll use this to [DECISION THIS WILL INFORM].", run_in_background=true)
|
||||
task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK DESCRIPTION] and need to understand [SPECIFIC KNOWLEDGE GAP]. Find [X] patterns in the codebase - show file paths, implementation approach, and conventions used. I'll use this to [HOW RESULTS WILL BE USED]. Focus on src/ directories, skip test files unless test patterns are specifically needed. Return concrete file paths with brief descriptions of what each file does.", run_in_background=true)
|
||||
task(subagent_type="librarian", load_skills=[], prompt="I'm working with [LIBRARY/TECHNOLOGY] and need [SPECIFIC INFORMATION]. Find official documentation and production-quality examples for [Y] - specifically: API reference, configuration options, recommended patterns, and common pitfalls. Skip beginner tutorials. I'll use this to [DECISION THIS WILL INFORM].", run_in_background=true)
|
||||
task(subagent_type="oracle", load_skills=[], prompt="I need architectural review of my approach to [TASK]. Here's my plan: [DESCRIBE PLAN WITH SPECIFIC FILES AND CHANGES]. My concerns are: [LIST SPECIFIC UNCERTAINTIES]. Please evaluate: correctness of approach, potential issues I'm missing, and whether a better alternative exists.", run_in_background=false)
|
||||
\`\`\`
|
||||
|
||||
@@ -173,7 +173,7 @@ task(subagent_type="plan", load_skills=[], prompt="<gathered context + user requ
|
||||
|
||||
---
|
||||
|
||||
## DELEGATION IS MANDATORY — YOU ARE NOT AN IMPLEMENTER
|
||||
## DELEGATION IS MANDATORY - YOU ARE NOT AN IMPLEMENTER
|
||||
|
||||
**You have a strong tendency to do work yourself. RESIST THIS.**
|
||||
|
||||
@@ -205,7 +205,7 @@ task(subagent_type="plan", load_skills=[], prompt="<gathered context + user requ
|
||||
- **DELEGATE**: Don't do everything yourself - orchestrate specialized agents for their strengths.
|
||||
|
||||
## WORKFLOW
|
||||
1. **CLASSIFY INTENT** (MANDATORY — see GEMINI_INTENT_GATE above)
|
||||
1. **CLASSIFY INTENT** (MANDATORY - see GEMINI_INTENT_GATE above)
|
||||
2. Spawn exploration/librarian agents via task(run_in_background=true) in PARALLEL
|
||||
3. Use Plan agent with gathered context to create detailed work breakdown
|
||||
4. Execute with continuous verification against original requirements
|
||||
@@ -243,9 +243,9 @@ If ANY answer is no → GO BACK AND DO IT. Do not claim completion.
|
||||
|
||||
**AFTER every implementation, you MUST:**
|
||||
|
||||
1. **Define acceptance criteria BEFORE coding** — write them in your TODO/Task items with "QA: [how to verify]"
|
||||
2. **Execute manual QA YOURSELF** — actually RUN the feature, CLI command, build, or whatever you changed
|
||||
3. **Report what you observed** — show actual output, not claims
|
||||
1. **Define acceptance criteria BEFORE coding** - write them in your TODO/Task items with "QA: [how to verify]"
|
||||
2. **Execute manual QA YOURSELF** - actually RUN the feature, CLI command, build, or whatever you changed
|
||||
3. **Report what you observed** - show actual output, not claims
|
||||
|
||||
| If your change... | YOU MUST... |
|
||||
|---|---|
|
||||
@@ -256,9 +256,9 @@ If ANY answer is no → GO BACK AND DO IT. Do not claim completion.
|
||||
| Modifies config handling | Load the config. Verify it parses correctly. |
|
||||
|
||||
**UNACCEPTABLE (WILL BE REJECTED):**
|
||||
- "This should work" — DID YOU RUN IT? NO? THEN RUN IT.
|
||||
- "lsp_diagnostics is clean" — That is a TYPE check, not a FUNCTIONAL check. RUN THE FEATURE.
|
||||
- "Tests pass" — Tests cover known cases. Does the ACTUAL feature work? VERIFY IT MANUALLY.
|
||||
- "This should work" - DID YOU RUN IT? NO? THEN RUN IT.
|
||||
- "lsp_diagnostics is clean" - That is a TYPE check, not a FUNCTIONAL check. RUN THE FEATURE.
|
||||
- "Tests pass" - Tests cover known cases. Does the ACTUAL feature work? VERIFY IT MANUALLY.
|
||||
|
||||
**You have Bash, you have tools. There is ZERO excuse for skipping manual QA.**
|
||||
</MANUAL_QA_MANDATE>
|
||||
|
||||
@@ -93,8 +93,8 @@ Use these when they provide clear value based on the decision framework above:
|
||||
**ALWAYS run both tracks in parallel:**
|
||||
\`\`\`
|
||||
// Fire background agents for deep exploration
|
||||
task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK] and need to understand [KNOWLEDGE GAP]. Find [X] patterns in the codebase — file paths, implementation approach, conventions used, and how modules connect. I'll use this to [DOWNSTREAM DECISION]. Focus on production code in src/. Return file paths with brief descriptions.", run_in_background=true)
|
||||
task(subagent_type="librarian", load_skills=[], prompt="I'm working with [TECHNOLOGY] and need [SPECIFIC INFO]. Find official docs and production examples for [Y] — API reference, configuration, recommended patterns, and pitfalls. Skip tutorials. I'll use this to [DECISION THIS INFORMS].", run_in_background=true)
|
||||
task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK] and need to understand [KNOWLEDGE GAP]. Find [X] patterns in the codebase - file paths, implementation approach, conventions used, and how modules connect. I'll use this to [DOWNSTREAM DECISION]. Focus on production code in src/. Return file paths with brief descriptions.", run_in_background=true)
|
||||
task(subagent_type="librarian", load_skills=[], prompt="I'm working with [TECHNOLOGY] and need [SPECIFIC INFO]. Find official docs and production examples for [Y] - API reference, configuration, recommended patterns, and pitfalls. Skip tutorials. I'll use this to [DECISION THIS INFORMS].", run_in_background=true)
|
||||
|
||||
// WHILE THEY RUN - use direct tools for immediate context
|
||||
grep(pattern="relevant_pattern", path="src/")
|
||||
@@ -122,7 +122,7 @@ deep_context = background_output(task_id=...)
|
||||
|
||||
**BEFORE implementation**, define what "done" means in concrete, binary terms:
|
||||
|
||||
1. Write acceptance criteria as pass/fail conditions (not "should work" — specific observable outcomes)
|
||||
1. Write acceptance criteria as pass/fail conditions (not "should work" - specific observable outcomes)
|
||||
2. Record them in your TODO/Task items with a "QA: [how to verify]" field
|
||||
3. Work toward those criteria, not just "finishing code"
|
||||
|
||||
@@ -160,7 +160,7 @@ A task is complete when:
|
||||
2. lsp_diagnostics shows zero errors on modified files
|
||||
3. Tests pass (or pre-existing failures documented)
|
||||
4. Code matches existing codebase patterns
|
||||
5. **Manual QA executed — actual feature tested, output observed and reported**
|
||||
5. **Manual QA executed - actual feature tested, output observed and reported**
|
||||
|
||||
**Deliver exactly what was asked. No more, no less.**
|
||||
|
||||
|
||||
@@ -4,12 +4,12 @@ export const TODOWRITE_DESCRIPTION = `Use this tool to create and manage a struc
|
||||
|
||||
Each todo title MUST encode four elements: WHERE, WHY, HOW, and EXPECTED RESULT.
|
||||
|
||||
Format: "[WHERE] [HOW] to [WHY] — expect [RESULT]"
|
||||
Format: "[WHERE] [HOW] to [WHY] - expect [RESULT]"
|
||||
|
||||
GOOD:
|
||||
- "src/utils/validation.ts: Add validateEmail() for input sanitization — returns boolean"
|
||||
- "UserService.create(): Call validateEmail() before DB insert — rejects invalid emails with 400"
|
||||
- "validation.test.ts: Add test for missing @ sign — expect validateEmail('foo') to return false"
|
||||
- "src/utils/validation.ts: Add validateEmail() for input sanitization - returns boolean"
|
||||
- "UserService.create(): Call validateEmail() before DB insert - rejects invalid emails with 400"
|
||||
- "validation.test.ts: Add test for missing @ sign - expect validateEmail('foo') to return false"
|
||||
|
||||
BAD:
|
||||
- "Implement email validation" (where? how? what result?)
|
||||
|
||||
Reference in New Issue
Block a user