sherpa-skill 2.0.6 → 2.0.7

package/skills/sherpa/workflows/research.md

@@ -0,0 +1,142 @@
+# sherpa — Research Workflow
+
+**Operation**: RESEARCH  
+**Purpose**: Evaluate research questions against evidence in a deterministic, evidence-based pipeline.  
+**Prerequisite:** sherpa must be initialized (`.sherpa/project-state.md` exists). If not, run INIT first.
+
+## When to Use
+
+Use RESEARCH when:
+- You have a specific research question about the hackathon project
+- You need evidence to support or refute a claim
+- You want to know what is known, unknown, or assumed about a topic
+- You need to research competitors, technologies, rules, or best practices
+
+## Workflow Steps
+
+### Step 1: Define the Research Question
+
+Read from `.sherpa/project-state.md`:
+- Hackathon name, deadline, time remaining
+- Judging criteria and weights (or UNKNOWN)
+- Problem statement
+- Target users (if known)
+
+Accept from user:
+- Research question (one sentence)
+- Scope (what is in scope, what is out of scope)
+- Depth (calibration, standard, deep)
+
+If no research question provided:
+- Report "No research question provided."
+- Ask user to supply a research question before research can run.
+- Stop.
+
+### Step 2: Research Plan
+
+Define:
+- What evidence is needed
+- Where to look (repository files, web search, team input, docs)
+- Evidence quality threshold
+- Time budget
+
+Record the plan in `.sherpa/evidence/research/<research-query>.md`.
+
+### Step 3: Retrieve
+
+Retrieve candidate evidence from:
+- Repository source code, config, tests, docs
+- Web search (if available and permitted)
+- Team input
+- Existing sherpa artifacts
+
+Save raw retrieval results to `.sherpa/evidence/research/`.
+
+### Step 4: Verify
+
+For each candidate evidence item:
+- Verify the source is real and accessible
+- Check the claim against the source text
+- Verify numbers, dates, entity names match exactly
+- Check polarity/negation
+- Check temporal consistency (dates, versions)
+
+### Step 5: Analyze
+
+Classify each claim as FACT, INFERENCE, ASSUMPTION, or UNKNOWN.
+
+### Step 6: Synthesize
+
+Combine evidence into a coherent answer. Address:
+- What is known
+- What is unknown
+- What assumptions must hold
+- What the evidence does and does not support
+
+### Step 7: Decide
+
+Determine what the research means for the project decision:
+- Does it support proceeding?
+- Does it raise blockers?
+- What assumptions must hold?
+- What is the recommended next action?
+
+### Step 8: Persist
+
+Save the research record to `.sherpa/evidence/research/<research-query>.md`.
+Include all evidence, gates, decisions, and unknowns.
+
+## 5. Evidence Model
+
+| Field | Values |
+|-------|--------|
+| type | FACT | INFERENCE | ASSUMPTION | UNKNOWN |
+| value | The claim |
+| source | URL, file path, or "team input" |
+| confidence | low | medium | high |
+
+Rules:
+- No claim may be tagged FACT unless directly verified from source
+- No claim may be tagged INFERENCE without explicit reasoning
+- ASSUMPTION must be explicitly marked as provisional
+- UNKNOWN means no information available
+- Never claim research was performed unless evidence was actually retrieved
+
+## 6. Source Priority
+
+Priority order for evidence:
+1. Official documentation / official repository / official specification
+2. Repository source code and tests (direct inspection)
+3. Team input (explicitly attributed)
+4. Secondary sources (blog posts, tutorials, secondary docs)
+5. General web search results (lowest confidence)
+
+## 7. Time Awareness
+
+- If remaining time is UNKNOWN, record TIME STRATEGY = UNKNOWN
+- Do not spend unlimited time on research
+- If time is limited, prefer repository evidence over web search
+
+## 8. Human Authority
+
+Research recommends; the human decides. Research does not:
+- Auto-approve ideas
+- Auto-approve architecture
+- Auto-approve implementation
+- Change the selected idea
+- Silently redesign architecture
+- Replace Phase 5/7/8 engines
+
+Research findings route to the appropriate phase but do not replace it.
+
+## 9. Output Contract
+
+After each research invocation, return:
+- Research question
+- Evidence found (with sources and confidence)
+- Contradictions found (if any)
+- Unknowns
+- Decision/recommendation
+- Exactly one PRIMARY NEXT ACTION
+
+All research artifacts live in `.sherpa/evidence/research/`.

package/skills/sherpa/workflows/score-optimization.md

@@ -0,0 +1,276 @@
+# sherpa — Score Optimization Workflow
+
+**Operation:** SCORE-OPTIMIZE  
+**Lifecycle Phase:** Phase 15 — Score Optimization Intelligence  
+**Purpose:** Answer "Given the official judging criteria, actual project evidence, judge simulation results, current implementation state, and remaining time, what changes provide the highest expected increase in judging score?" Produce a prioritized optimization plan. Phase 15 optimizes score, not feature count.
+
+## Prerequisites
+
+- `.sherpa/project-state.md` must exist
+- `selected idea` must be known (not UNKNOWN)
+- Phase 2 idea evaluation evidence must exist
+- Phase 3 project plan evidence must exist
+- Phase 4 implementation evidence must exist
+- Phase 5 testing/security evidence must exist
+- Phase 7 UX evidence must exist
+- Phase 8 Red Team evidence must exist
+- Phase 9 Judge Simulation report must exist (`.sherpa/judge-simulation.md`)
+- Judging criteria and weights must be identified (KNOWN) or explicitly marked UNKNOWN
+
+If any prerequisite is missing, mark it UNKNOWN, report SCORE-OPTIMIZE = BLOCKED or LIMITED, and do not invent criteria, weights, or evidence.
+
+## Pipeline
+
+### Stage 1: Read Project State
+
+Read `.sherpa/project-state.md` and capture:
+
+- Hackathon name, deadline, time remaining
+- Phase
+- Selected idea
+- Judging criteria and weights
+- Current estimated score, potential score (if previously recorded)
+- Largest gaps (if previously recorded)
+- Highest-priority improvement (if previously recorded)
+- Time-aware strategy category
+
+### Stage 2: Read Prior-Phase Evidence
+
+Consume (do not duplicate or replace) the following evidence:
+
+| Phase | Source | What to consume |
+|-------|--------|-----------------|
+| Phase 2 | `.sherpa/decisions.md`, `.sherpa/evaluations/<idea>.md` | Selected idea, evaluation scores, differentiation, MVP scope |
+| Phase 3 | `.sherpa/evidence/project-plan-*.md` | Architecture, MVP scope (MUST/SHOULD/OPTIONAL/EXCLUDED), workstreams, dependencies, critical path, technical risks, time strategy |
+| Phase 4 | `.sherpa/evidence/` implementation artifacts | Repository baseline, components implemented, tests executed, deployment configuration, known issues |
+| Phase 5 | `.sherpa/evidence/` testing/security artifacts | Test results, security findings, blocked tests, regression risks, known failures |
+| Phase 7 | `.sherpa/ux-review.md`, `.sherpa/ux/` artifacts | UX baseline, critical flows, findings, quality gate status, limitations |
+| Phase 8 | `.sherpa/red-team.md`, `.sherpa/red-team/` artifacts | Red team findings, risks, mitigations, quality gate status, limitations |
+| Phase 9 | `.sherpa/judge-simulation.md` | Judge simulation report, criterion-by-criterion observations, judge concerns, judge trust, differentiation perception |
+
+Do not re-run Phase 2–9 engines. Consume their evidence only.
+
+Flag contradictory claims between phases or between documentation and repository:
+
+```text
+Documentation says X
+Repository does Y
+Phase 9 simulation says Z
+```
+
+Do not silently reconcile contradictions. Record them as separate findings.
+
+### Stage 3: Inspect Current Repository
+
+Inspect the actual repository:
+
+- Project metadata
+- Dependency manifests
+- Top-level project structure
+- Application entry points
+- Frontend/backend/database/AI components
+- APIs
+- Tests
+- Deployment configuration
+- Documentation
+- Environment configuration
+
+Classify every observation as FACT, INFERENCE, ASSUMPTION, or UNKNOWN. Cite repository path/line or execution result.
+
+Rules:
+- Never fabricate repository facts.
+- Seeing a file does not mean it works.
+- Generated sherpa artifacts are not independent evidence.
+
+### Stage 4: Build Score Model
+
+For each official judging criterion:
+
+1. Map criterion to contributing evidence from Phases 2–9 and repository inspection.
+2. Assign a current performance level (1–10 scale) with evidence type and confidence.
+3. Use official criterion weight if KNOWN. If weights are UNKNOWN, mark UNKNOWN and use a clearly labeled PROVISIONAL equal-weight model only for prioritization. Never pretend provisional weights are official.
+4. Calculate weighted contribution = criterion score × criterion weight.
+5. Label every score estimate: OFFICIAL, ESTIMATED, PROVISIONAL, or UNKNOWN.
+6. Do not fabricate numerical precision (e.g., do not report "exactly 23.7/30" without supporting evidence).
+
+Score model record:
+
+```
+Criterion Score = Evidence-backed performance level (1–10)
+Weighted Contribution = Criterion Score × Criterion Weight
+Total Estimated Score = Σ(Weighted Contributions) / Σ(Weights)
+```
+
+### Stage 5: Gap Analysis
+
+For every criterion, complete a gap analysis using `templates/gap-analysis.md`:
+
+| Field | Description |
+|-------|-------------|
+| Criterion | Official judging criterion name |
+| Official Weight | Weight or UNKNOWN |
+| Current Evidence | Summary of evidence backing current level |
+| Current Performance | 1–10 with confidence |
+| Confidence | HIGH / MEDIUM / LOW / UNKNOWN |
+| Strengths | What is working well |
+| Weaknesses | What is weak |
+| Evidence Gap | Weak project performance vs weak evidence of performance (separate findings) |
+| Judge Visibility | How observable is this to a judge |
+| Improvement Potential | NONE / LOW / MEDIUM / HIGH / CRITICAL / UNKNOWN |
+| Risk | Risk of attempting improvement |
+
+Classify the gap:
+- **NONE** — No meaningful gap
+- **LOW** — Small gap
+- **MEDIUM** — Moderate gap
+- **HIGH** — Large gap
+- **CRITICAL** — Severe gap threatening scoring
+- **UNKNOWN** — Insufficient evidence to classify
+
+Separate findings:
+- **Weak project performance** — The capability itself is weak
+- **Weak evidence of project performance** — The capability may exist but is not demonstrated/documented
+
+### Stage 6: Generate Improvement Candidates
+
+For every criterion with a gap (LOW or higher), generate improvement candidates. Each candidate must belong to one or more categories:
+
+| Category | Description |
+|----------|-------------|
+| A. Differentiation | Improves uniqueness or competitive positioning |
+| B. Technical Credibility | Improves architecture quality, engineering quality, reliability, robustness, technical depth |
+| C. Core Functionality | Improves the primary user-facing value |
+| D. Demo Impact | Makes the core flow clearer, faster, more impressive, more reliable |
+| E. UX | Improves usability, clarity, accessibility, responsive behavior, interaction quality |
+| F. Security / Trust | Improves security, privacy, validation, resilience, trust |
+| G. Evidence | Improves the ability to prove an existing capability works |
+| H. Presentation | Presentation-related score opportunities within current phase scope only (no PPT creation; Phase 17 owns presentation) |
+| I. Reliability | Improves stability and reduces judge-visible failure risk |
+
+For each candidate, identify:
+- What specifically would change
+- Which criterion it improves
+- Evidence label (FACT / INFERENCE / ASSUMPTION / UNKNOWN) for the claim that this change helps
+- Dependencies or blockers
+- What explicitly should NOT be changed (to protect stable, high-scoring areas)
+
+### Stage 7: Evaluate Each Candidate
+
+For each improvement candidate, use `templates/improvement-candidate.md` and evaluate:
+
+| Dimension | Scale |
+|-----------|-------|
+| Score Impact | VERY LOW / LOW / MEDIUM / HIGH / VERY HIGH |
+| Confidence | HIGH / MEDIUM / LOW / UNKNOWN |
+| Judge Visibility | LOW / MEDIUM / HIGH / VERY HIGH |
+| Implementation Cost | TRIVIAL / LOW / MEDIUM / HIGH / VERY HIGH |
+| Risk | LOW / MEDIUM / HIGH / CRITICAL / UNKNOWN |
+
+**OPTIMIZATION HEURISTIC** (prioritization heuristic only, NOT judging mathematics):
+
+```
+Expected Value = Score Impact × Confidence × Judge Visibility ÷ Implementation Cost
+```
+
+Label this clearly as **OPTIMIZATION HEURISTIC**. Do not present it as judging mathematics. Use qualitative values where numerical precision is unsupported.
+
+Also identify:
+- Time required
+- Whether the improvement is worth doing
+- Time-aware filtering (apply lifecycle time-aware strategy)
+
+### Stage 8: Classify Priorities
+
+Assign exactly one priority to every candidate:
+
+| Priority | Definition |
+|----------|------------|
+| **P0 — CRITICAL** | Must address because it threatens judging readiness, core demo, major criterion, reliability, security, or submission viability |
+| **P1 — HIGH IMPACT** | Strong score improvement with realistic implementation cost |
+| **P2 — MEDIUM IMPACT** | Useful improvement but not essential |
+| **P3 — LOW IMPACT** | Minor polish |
+| **DROP** | Do not implement |
+
+Every optimization must receive exactly one priority.
+
+### Stage 9: Build Prioritized Optimization Plan
+
+Use `templates/score-optimization-plan.md` to produce the output plan:
+
+1. Current evidence-backed score position (criterion-by-criterion)
+2. Strongest scoring dimensions
+3. Weakest scoring dimensions
+4. Largest score gaps
+5. Prioritized improvement list (P0 first, then P1, P2, P3, then DROP)
+6. Smallest set of actions likely to produce the largest judging improvement
+7. What should explicitly NOT be changed
+8. Time-aware filtering applied
+
+### Stage 10: Update Project State
+
+Update ONLY these compact fields in `.sherpa/project-state.md`:
+
+| Field | Allowed Values |
+|-------|---------------|
+| Score Optimization Status | NOT_STARTED | IN_PROGRESS | BLOCKED | COMPLETE |
+| Current Estimated Score | <score or UNKNOWN> |
+| Potential Score | <score or UNKNOWN> |
+| Largest Gaps | <concise list or UNKNOWN> |
+| Highest-Priority Improvement | <concise or UNKNOWN> |
+
+Rules:
+- Do NOT put detailed optimization analysis inside project-state.md.
+- Detailed material goes to `.sherpa/score-optimization.md` and `.sherpa/score-optimization/`.
+- Do not change `selected idea`.
+- Do not silently change architecture.
+- Do not silently redesign architecture; architecture changes require human approval.
+- Do not silently modify application code.
+- Do not silently modify Phase 1–9 artifacts.
+- Human approval required for major scope or architecture changes.
+
+### Stage 11: Return Exactly One Primary Next Action
+
+Output format:
+
+```
+PRIMARY NEXT ACTION: <exactly one action>
+
+WHY: <explanation based on impact, time, risk, and judging criteria>
+
+DONE WHEN: <clear definition of done>
+
+Time remaining: <hours or UNKNOWN>
+
+Blocked by: <blocker or "None">
+```
+
+Rule: Exactly one primary next action. Do not produce competing alternatives.
+
+## Validation Checklist
+
+After SCORE-OPTIMIZE completes:
+
+- [ ] Project state read and verified
+- [ ] Phase 2–4, 11–14 evidence consumed (not duplicated)
+- [ ] Repository inspected for evidence
+- [ ] Score model built with official or explicitly provisional weights
+- [ ] Every score labeled OFFICIAL / ESTIMATED / PROVISIONAL / UNKNOWN
+- [ ] No false numerical precision claimed
+- [ ] Gap analysis completed for every criterion
+- [ ] Weak project performance separated from weak evidence of performance
+- [ ] Improvement candidates generated for all gapped criteria
+- [ ] Each candidate assigned to one or more categories (A–I)
+- [ ] Each candidate evaluated with Score Impact, Confidence, Judge Visibility, Cost, Risk
+- [ ] OPTIMIZATION HEURISTIC labeled as heuristic, not judging mathematics
+- [ ] Every candidate assigned exactly one priority (P0–P3 or DROP)
+- [ ] Prioritized optimization plan produced
+- [ ] Smallest set of high-impact actions identified
+- [ ] What NOT to change identified
+- [ ] Time-aware filtering applied
+- [ ] Project state updated with compact fields only
+- [ ] No Phase 1–9 artifacts modified
+- [ ] No application source code modified
+- [ ] No PPT created
+- [ ] No final submission performed
+- [ ] No postmortem performed
+- [ ] Exactly ONE primary next action returned

package/skills/sherpa/workflows/status.md

@@ -0,0 +1,107 @@
+# sherpa — STATUS Workflow
+
+**Operation**: STATUS  
+**Purpose**: Accurately report the current project state by reading `.sherpa/project-state.md` and inspecting the repository for evidence.
+
+## When to Use
+
+Use STATUS when:
+- You want to know where you are in the hackathon
+- You want to know what's complete, what's in progress, what's blocked
+- You want to know your biggest risks and what's incomplete
+- You need a snapshot before deciding what to do next
+
+## Workflow Steps
+
+### Step 1: Verify State Exists
+
+Check if `.sherpa/project-state.md` exists in the current project repository.
+
+If it does NOT exist:
+- Report that sherpa has not been initialized for this project
+- Recommend running INIT first
+- Stop
+
+### Step 2: Read Project State
+
+Read `.sherpa/project-state.md` and capture:
+- Hackathon name, deadline, time remaining
+- Phase
+- Problem statement, selected idea, MVP scope
+- Tech stack, architecture
+- Completed work, current work, blocked work
+- Risks, known weaknesses, open questions
+- Current estimated score, potential score
+- Demo status, PPT status, documentation status
+
+### Step 3: Inspect Repository for Evidence
+
+Inspect the repository to verify claims in the state file. Look for:
+- `package.json`, `requirements.txt`, `pyproject.toml` (tech stack verification)
+- Source code files (implementation evidence)
+- README (documentation evidence)
+- Test files (testing evidence)
+- Deployment configuration (deployment evidence)
+- Environment configuration (secrets/config evidence)
+
+Do NOT make claims about the project without evidence when the repository can be inspected.
+
+### Step 4: Compare State to Reality
+
+Identify gaps between what `.sherpa/project-state.md` says and what the repository shows:
+- State says "Authentication implemented" but no auth code exists → flag discrepancy
+- State says "Tests passing" but no test files exist → flag discrepancy
+- State says "Deployed" but no deployment config exists → flag discrepancy
+
+### Step 5: Calculate Time Remaining
+
+If deadline is known, calculate time remaining from current date/time. If deadline is `UNKNOWN`, report time remaining as `UNKNOWN`.
+
+### Step 6: Report Status
+
+Present a structured status report:
+
+```
+sherpa Status — [Hackathon Name]
+
+Phase: [phase]
+Time remaining: [time or UNKNOWN]
+
+Project State:
+  Problem: [problem statement or UNKNOWN]
+  Selected idea: [idea or UNKNOWN]
+  MVP scope: [MVP or UNKNOWN]
+  Tech stack: [stack or UNKNOWN]
+
+Completed: [list or UNKNOWN]
+In progress: [list or UNKNOWN]
+Blocked: [list or UNKNOWN]
+
+Risks: [list or UNKNOWN]
+Known weaknesses: [list or UNKNOWN]
+Open questions: [list or UNKNOWN]
+
+Scores:
+  Current estimated: [score or UNKNOWN]
+  Potential: [score or UNKNOWN]
+
+Deliverables:
+  Demo: [status or UNKNOWN]
+  PPT: [status or UNKNOWN]
+  Documentation: [status or UNKNOWN]
+
+Evidence Gaps (state vs repository):
+  [any discrepancies found]
+
+Biggest Current Risk: [single risk or UNKNOWN]
+```
+
+## Validation
+
+After STATUS completes:
+- [ ] `.sherpa/project-state.md` was read
+- [ ] Repository was inspected for evidence
+- [ ] No claims made without evidence
+- [ ] Discrepancies between state and reality are flagged
+- [ ] Time remaining is calculated or marked UNKNOWN
+- [ ] Biggest current risk is identified (one risk, not a list)

package/skills/sherpa/workflows/submission.md

@@ -0,0 +1,46 @@
+# sherpa — SUBMISSION-PREPARE Workflow
+
+**Lifecycle Phase:** Phase 19 — Submission Intelligence  
+**Purpose:** Prepare, verify, and freeze submission materials without submitting them.
+
+## Hard prerequisites
+
+1. Read `workflows/lifecycle.md`; require exactly 20 phases in order: Phase 18 Final Audit, Phase 19 Submission, Phase 20 Post-Mortem. Do not renumber or repair.
+2. Read `.sherpa/final-audit.md`; require `Audit status: COMPLETE`. If the artifact is absent or incomplete, stop and report the blocker. Never substitute a framework test report for project audit evidence.
+3. Inspect the Phase 18 project evidence and applicable Phase 1–18 contracts. Preserve prior project decisions and artifacts.
+4. Do not perform an actual competition submission or begin Phase 20.
+
+## Procedure
+
+1. Read `.sherpa/project-state.md` and prior phase evidence if present. If absent, record that no live project state was inspected; do not treat this framework repository as the project package.
+2. Inspect the actual current repository and its metadata. Cite paths, command output, hashes, or captured evidence. Separate observed FACT from INFERENCE and UNKNOWN. Never simulate inspection.
+3. Discover requirements using the authority order in `rules/submission-rules.md`. Record each in the requirement template. Preserve source conflicts; do not invent mandatory requirements.
+4. Record deadline, timezone, source, confidence, status and time remaining. Unknown deadline/timezone stays UNKNOWN; use the documented deadline strategy only where actual time is known.
+5. Inventory only existing/identified artifacts. Record version/location/access/verification independently. Do not claim an artifact exists because a template names it.
+6. Map submission fields from evidence; unknown or personal/team data remain UNKNOWN. Apply limits/formats only when an authoritative source provides them.
+7. Check each known URL for syntax, destination, content, access, authentication and expiry where actual verification can be performed. Record method/result/time. Unchecked links remain UNKNOWN.
+8. Verify permissions for intended judges. Restricted required artifacts are blockers unless official rules permit restricted access. Do not expose secrets or change visibility.
+9. Audit repository identity, branch, intended commit, README/setup, required files, links, sensitive data, debug artifacts and configuration. Report setup only as verified if it was actually run and evidence recorded; do not install dependencies or alter source.
+10. Verify deployment, demo/video, presentation, formats and limits only against actual artifacts and official requirements. If not available, set UNKNOWN. Do not redesign these artifacts.
+11. Build consistency and claim matrices across form, README, PPT, demo, repository, deployment, project description, selected idea and Phase 18 audit. Preserve contradictions as findings. Unsupported/contradicted claims are not submission-ready.
+12. Run a bounded secret/sensitive-data check on the recorded scope. State the exact scope and method; never claim absolute absence.
+13. Build the risk register, snapshot, and change classification. Values unavailable in repository metadata are UNKNOWN. Activate submission freeze only once all critical artifacts are verified.
+14. Determine readiness from evidence using the gate in the rules. Missing live package or official requirements implies CONDITIONAL at best; do not claim READY_TO_SUBMIT from framework tests.
+15. Present `FINAL HUMAN CONFIRMATION REQUIRED` and the final checklist. “Submission performed” must remain unchecked. Never invoke portal actions, upload, publish, change visibility, or submit.
+16. Record exactly one `PRIMARY NEXT ACTION`.
+
+## Required outputs
+
+Use the Phase 19 templates for requirement records, inventory, field mapping, links, risks, checklist, snapshot, and verification. Produce `.sherpa/submission-plan.md` and detailed evidence under `.sherpa/submission/` only in the actual project repository. Contract harnesses report to stdout and do not create repository audit reports. Keep `.sherpa/project-state.md` compact and add only the Phase 19 fields specified below; do not overwrite prior phase state.
+
+### Additive project-state fields only
+
+Submission Status; Submission Readiness; Submission Deadline; Deadline Timezone; Submission Requirements; Artifact Inventory; Required Fields; URL Verification; Access Verification; Submission Snapshot; Freeze Status; Critical Submission Risks; Human Confirmation Status; Current Submission Blocker; Primary Next Action.
+
+## Final report sections
+
+Prerequisites; Lifecycle Integrity; Submission Requirements; Deadline Verification; Artifact Inventory; Field Verification; URL Verification; Access Verification; Repository Audit; Demo/Video Audit; PPT Audit; README Audit; Secret Audit; Consistency Audit; Claim Audit; Risk Register; Submission Snapshot; Freeze Status; Human Confirmation; Submission Readiness; Scope Compliance; Evidence Integrity; Primary Next Action; Final Decision.
+
+## Readiness and phase lock are distinct
+
+Phase 19 framework may be COMPLETE & LOCKED while live Submission Readiness remains CONDITIONAL. Framework contract tests do not verify live portal rules, package, links, artifact access, deployment, video, presentation, or deadline. Actual submission is a human action outside this workflow.

package/skills/sherpa/workflows/testing-security.md

@@ -0,0 +1,44 @@
+# sherpa — TESTING + SECURITY Workflow
+
+**Operation:** TESTING-SECURITY (Phase 5)  
+**Purpose:** Evaluate implemented scope using real test/security evidence and a time-aware quality gate.
+
+## Routing
+
+Use for TEST, TESTING, SECURITY, SECURITY REVIEW, RUN TESTS, CHECK SECURITY, TEST PROJECT, AUDIT SECURITY, or VERIFY IMPLEMENTATION. A general “what next?” remains owned by `workflows/next.md`. Follow `rules/testing-security-rules.md`. Phase 4 files are frozen; do not modify them. Do not start Phase 6.
+
+## Deterministic Workflow
+
+1. **Read state first.** Read `.sherpa/project-state.md`. Verify the selected idea and implementation status. If implementation is `NOT_STARTED`, return `Testing blocked until implementation exists.` Do not claim testing readiness.
+2. **Read approved plans.** Read the Phase 3 project plan and Phase 4 implementation plan at their recorded paths. Identify the approved MVP, implemented scope, critical flows, architecture, and recent changes. Missing plans/status are `UNKNOWN`/`BLOCKED`; do not infer completion.
+3. **Inspect actual baseline.** Record repository root/revision when available, runtime/framework, frontend/backend, test frameworks and files, scripts, build/lint/typecheck commands, API/E2E/CI setup, fixtures/mocks, config/environment names, and known failures. Mark unavailable items UNKNOWN. Do not install dependencies.
+4. **Create/update test plan.** Use `templates/test-plan.md` at `.sherpa/test-plan.md`. Plan only applicable categories. Map critical user flows and MUST HAVE behavior first; include security-sensitive paths, regression-prone areas, then lower-priority checks. Include expected results, priority, dependencies, and status.
+5. **Prioritize for available time.** Apply `rules/testing-security-rules.md` Section 7. If time is UNKNOWN, write `TIME STRATEGY = UNKNOWN` and keep priorities time-neutral.
+6. **Execute applicable checks.** Run only checks supported by the observed environment and relevant to scope. Capture exact command/procedure and direct result. If unavailable, record BLOCKED/UNKNOWN. Never treat build success as full test/security success.
+7. **Record each result.** Use `templates/test-result.md` under `.sherpa/testing/test-NNN.md`. Preserve failures and output. Mark unrun checks PLANNED/UNKNOWN/BLOCKED, never PASSED.
+8. **Analyze failures.** Record affected flow, impact, blocking status, and likely cause separately from evidence. Do not hide or relabel a failure. Route source fixes through the Phase 4 implementation process; Phase 5 records remediation and verifies it after implementation.
+9. **Perform bounded security review.** Use `templates/security-review.md` at `.sherpa/security-review.md`. State scope, method, limitations, unknowns, and findings. Inspect applicable security areas listed in the rules. Use FACT/INFERENCE/ASSUMPTION/UNKNOWN and severity/confidence separately. Do not claim no vulnerabilities beyond scope.
+10. **Audit dependencies when possible.** Use an already-available project-native auditor, record exact command and output. If unavailable, record dependency security status UNKNOWN; do not install an auditor or upgrade packages.
+11. **Record and prioritize findings.** Create `.sherpa/security/finding-NNN.md` from `templates/security-finding.md`. Prioritize by severity, exploitability, impact, surface, confidence, and MVP relevance. Do not call a proposed fix FIXED.
+12. **Verify remediation and regressions.** For each implemented fix, run focused verification plus directly affected tests, related tests, critical-flow tests, and security regressions as applicable. Record evidence. If regression cannot run, finding remains BLOCKED/UNKNOWN and is not verified.
+13. **Evaluate quality gate.** Set `READY` only under rules Section 6. Critical failures or unresolved/unverified critical findings prevent READY. Use BLOCKED/CONDITIONAL when critical evidence is missing or lower-severity/unknown issues remain material.
+14. **Update compact state.** Update only Phase 5 fields allowed by rules Section 8. Keep detail in artifacts. Do not change idea, architecture, MVP, or Phase 4 fields.
+15. **Return exactly one primary next action.** State scope, baseline, critical test/security outcomes, direct evidence, failures, unknowns, gate, and one next action. Do not begin Phase 6.
+
+## Failure Cases
+
+- `Implementation status = NOT_STARTED`: `Testing blocked until implementation exists.`
+- Missing tests: `UNKNOWN` / `NOT PRESENT`, not FAILED.
+- Test command fails: record FAILED and output; rerun after any fix.
+- Test environment broken: BLOCKED.
+- Security evidence insufficient: UNKNOWN, with scope/limitations.
+- Dependency auditor unavailable: dependency security UNKNOWN.
+- Unverified fix: finding remains OPEN/IN_PROGRESS/BLOCKED, never FIXED.
+- Critical unresolved failure/finding: gate is not READY.
+- Unknown time: `TIME STRATEGY = UNKNOWN`.
+- Requested architecture redesign: `ARCHITECTURE CHANGE REQUIRED`; defer to human-controlled architecture process.
+- Request to change selected idea: preserve it; human decision required.
+
+## Output Contract
+
+Return exactly one `PRIMARY NEXT ACTION`; do not create a parallel NEXT engine or continue to Phase 6.