sherpa-skill 2.0.6 → 2.0.7

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

@@ -0,0 +1,355 @@
+# sherpa — Score Optimization Rules
+
+**Lifecycle Phase:** Phase 15 — Score Optimization Intelligence  
+**Purpose:** Authoritative rules for score optimization. Phase 15 reviews and recommends; it does not implement, replace prior phases, or modify locked artifacts.
+
+---
+
+## 1. Purpose and Boundaries
+
+Phase 10 answers: "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?"
+
+Phase 10 optimizes **score**, not feature count.
+
+### Phase 15 MAY:
+
+- Inspect official judging criteria
+- Inspect Phase 2 evaluation evidence
+- Inspect Phase 3 engineering evidence
+- Inspect Phase 4 implementation evidence
+- Inspect Phase 5 testing/security evidence
+- Inspect Phase 7 UX evidence
+- Inspect Phase 8 red-team evidence
+- Inspect Phase 9 judge simulation
+- Inspect repository/project evidence
+- Identify score gaps
+- Estimate score impact
+- Compare improvement options
+- Prioritize improvements
+- Identify quick wins
+- Identify high-risk improvements
+- Identify non-worthwhile work
+- Create a score optimization plan
+- Create prioritized optimization tasks
+- Recommend what to implement next
+- Update Phase 10 artifacts and project state
+
+### Phase 15 MUST NOT:
+
+- Redesign the idea
+- Re-run idea generation
+- Replace architecture
+- Own implementation
+- Replace testing/security
+- Replace UX review
+- Replace red-team review
+- Replace judge simulation
+- Create PPT
+- Perform final submission
+- Perform postmortem
+- Silently modify application code
+- Silently modify Phase 1–9 artifacts
+- Silently redesign architecture; architecture changes require HUMAN ARCHITECTURE APPROVAL
+- Recommend duplicate or unnecessary functionality that adds cost without score impact
+- Claim score improvements without evidence
+- Invent judging criteria
+- Invent judge feedback
+- Treat estimated scores as official scores
+
+---
+
+## 2. Evidence Model
+
+Every important optimization claim must identify its evidence status.
+
+Allowed evidence labels:
+
+| Label | Definition |
+|-------|------------|
+| FACT | Directly observed from repository inspection, verified execution, or external source |
+| INFERENCE | Logical conclusion drawn from observed facts |
+| ASSUMPTION | Not yet verified; requires confirmation |
+| UNKNOWN | No information available; not observed |
+
+Rules:
+
+- Never convert UNKNOWN into a favorable assumption.
+- No dimension score or gap classification may be justified by UNKNOWN or ASSUMPTION without explicit flagging.
+- Every observation cites reproducible evidence: path/line, route/screen, steps, result, or evidence artifact.
+- Generated sherpa artifacts are not independent evidence. Evidence must trace back to repository inspection, actual execution, external verification, or explicit human-provided information.
+- Do not treat previous AI-generated recommendations as facts.
+
+Example:
+
+GOOD:
+
+> FACT — Official judging criterion gives Technical Implementation 30%.
+>
+> INFERENCE — Improving reliability may materially improve technical and demo perception.
+>
+> UNKNOWN — Actual judge score impact cannot be known before judging.
+
+BAD:
+
+> Improving reliability will increase the score by 8 points.
+
+Unless there is actual evidence supporting that numerical claim.
+
+---
+
+## 3. Score Model
+
+Build a transparent score model.
+
+### 3.1 Criterion Weights
+
+If official criterion weights exist (KNOWN from hackathon rules):
+
+Use them. Label as OFFICIAL.
+
+If official weights do not exist (UNKNOWN):
+
+- Mark weights UNKNOWN
+- Use a clearly labeled PROVISIONAL equal-weight model only for prioritization
+- Never pretend provisional weights are official
+- Explicitly state: "Judging criteria unknown; score based on equal-weight provisional assessment"
+
+### 3.2 Score Formula
+
+```
+Criterion Score = Evidence-backed performance level (1–10)
+Weighted Contribution = Criterion Score × Criterion Weight
+Total Estimated Score = Σ(Weighted Contributions) / Σ(Weights)
+```
+
+### 3.3 Score Labels
+
+All score estimates must be labeled:
+
+| Label | Meaning |
+|-------|---------|
+| OFFICIAL | Score comes from official judging rubric or verified judge feedback |
+| ESTIMATED | Score is estimated from evidence with clear reasoning |
+| PROVISIONAL | Score uses provisional/equal weights because official weights are UNKNOWN |
+| UNKNOWN | Insufficient evidence to assign a score |
+
+### 3.4 Numerical Precision
+
+Do not fabricate numerical precision.
+
+GOOD:
+
+```
+Technical Implementation:
+Current assessment: 7/10
+Confidence: MEDIUM
+Weight: 30% OFFICIAL
+Estimated contribution: 21/30
+```
+
+BAD:
+
+```
+Technical score = exactly X.Y/30
+```
+
+Claiming decimal precision without supporting evidence. Report whole numbers or clearly labeled ranges unless evidence supports finer precision.
+
+---
+
+## 4. Gap Analysis
+
+For every criterion, determine:
+
+| 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 |
+
+Gap classification:
+
+| Classification | Meaning |
+|----------------|---------|
+| NONE | No meaningful gap |
+| LOW | Small gap |
+| MEDIUM | Moderate gap |
+| HIGH | Large gap |
+| CRITICAL | Severe gap threatening scoring |
+| UNKNOWN | Insufficient evidence to classify |
+
+### 4.1 Separate Findings
+
+Do not confuse:
+
+**Weak project performance** — The capability itself is weak
+
+with
+
+**Weak evidence of project performance** — The capability may exist but is not demonstrated, documented, or observable by a judge.
+
+These must be separate findings. A project may have strong internal implementation (weak evidence = fixable with documentation/demo) or weak implementation (weak project performance = requires actual code change).
+
+---
+
+## 5. Improvement Categories
+
+Every proposed improvement must belong to one or more categories:
+
+| ID | 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, or more reliable |
+| E | UX | Improves usability, clarity, accessibility, responsive behavior, or interaction quality |
+| F | Security / Trust | Improves security, privacy, validation, resilience, or trust |
+| G | Evidence | Improves the ability to prove that an existing capability works |
+| H | Presentation | Presentation-related score opportunities within current phase scope only. Do not create PPT content; Phase 17 owns presentation. |
+| I | Reliability | Improves stability and reduces judge-visible failure risk |
+
+---
+
+## 6. Improvement Value Model
+
+Each candidate improvement must be evaluated using:
+
+| 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, NOT judging mathematics):
+
+```
+Expected Value = Score Impact × Confidence × Judge Visibility ÷ Implementation Cost
+```
+
+Rules:
+
+- Clearly label this as **OPTIMIZATION HEURISTIC**.
+- Do not present it as judging mathematics.
+- Use qualitative values where numerical precision is unsupported.
+- The heuristic ranks candidates for prioritization; it does not produce official scores.
+
+Each candidate must also identify:
+
+- Time required
+- Dependencies / blockers
+- Whether the improvement is actually worth doing
+- What should explicitly NOT be changed (to protect stable, high-scoring areas)
+
+---
+
+## 7. Priority Classification
+
+Every optimization must receive exactly one priority:
+
+| Priority | Definition | Action |
+|----------|------------|--------|
+| **P0 — CRITICAL** | Must address because it threatens judging readiness, core demo, major criterion, reliability, security, or submission viability | Implement first; human approval if architecture/scope change |
+| **P1 — HIGH IMPACT** | Strong score improvement with realistic implementation cost | Implement after P0 items |
+| **P2 — MEDIUM IMPACT** | Useful improvement but not essential | Implement if time permits after P0/P1 |
+| **P3 — LOW IMPACT** | Minor polish | Implement only if all higher priorities complete and time remains |
+| **DROP** | Do not implement | Explicitly rejected; document reason |
+
+Every candidate must receive exactly one priority. No candidate may be unclassified.
+
+---
+
+## 8. Time-Aware Filtering
+
+Apply the lifecycle time-aware strategy:
+
+| Time Remaining | Allow | Block |
+|----------------|-------|-------|
+| > 24 hours | Core product, differentiation, architecture, important features, validation | Low-judging-value features |
+| 12–24 hours | Completing MVP, high-impact features, integration, testing | New feature exploration |
+| 6–12 hours | Stability, testing, UX, security, demo reliability, presentation | Architectural changes |
+| 2–6 hours | Bug fixing, demo flow, critical polish, PPT, documentation, deployment reliability | Any new feature development |
+| < 2 hours | Build working, deployment working, demo working, PPT accurate, links working, critical bugs fixed, submission requirements satisfied | All feature development |
+
+If time remaining is UNKNOWN:
+
+- Mark it UNKNOWN
+- Produce a time-neutral plan
+- Recommend establishing the deadline if necessary
+
+---
+
+## 9. Project State Fields
+
+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 modify application code.
+- Do not silently modify Phase 1–9 artifacts.
+- Human approval required for major scope or architecture changes.
+
+---
+
+## 10. Failure Cases
+
+| Case | Behavior |
+|------|----------|
+| No selected idea | Stop and request confirmation |
+| Missing Phase 9 judge simulation | Report SCORE-OPTIMIZE = LIMITED; proceed with available evidence, mark gaps UNKNOWN |
+| Missing judging criteria | Mark UNKNOWN; use provisional equal-weight model; state explicitly |
+| Missing repository evidence | Lower confidence; mark unknowns explicitly; do not fabricate |
+| Unsupported score claim | Flag as unsupported; do not treat as verified |
+| Contradictory claims | Record contradiction; do not silently reconcile |
+| Architecture change required | Record ARCHITECTURE CHANGE REQUIRED; route to HUMAN ARCHITECTURE APPROVAL; stop that remediation |
+| Idea change attempt | Blocked; route back to Phase 2 / human |
+| Unknown deadline | Do not assume one; mark TIME STRATEGY = UNKNOWN |
+| Already-mitigated finding | If finding is VERIFIED_MITIGATED, do not optimize against the resolved issue; record as resolved |
+
+Phase 15 MUST NOT:
+
+- Write application code
+- Modify application source files
+- Modify frontend/backend implementation
+- Install dependencies
+- Deploy the application
+- Change the selected idea
+- Silently redesign architecture
+- Replace Phase 5 testing/security
+- Replace Phase 7 UX review
+- Replace Phase 8 Red Team
+- Replace Phase 9 Judge Simulation
+- Perform final presentation generation
+- Perform final submission
+- Perform post-mortem
+- Fabricate judge opinions
+- Claim judge reactions without evidence
+- Claim score improvements without evidence
+- Silently override Phase 8 or Phase 9 decisions
+
+---
+
+## 11. Determinism
+
+Same evidence, criteria, weights, and time remaining → same optimization plan and priority classifications every time. No randomness. No LLM-generated numeric scores without explicit numeric input.

package/skills/sherpa/rules/scoring-rules.md

@@ -0,0 +1,216 @@
+# sherpa — Scoring Rules
+
+Defines the Idea Intelligence Engine scoring model. All scores are deterministic:
+- Same evidence, criteria, weights, team capability, and time → same score and recommendation.
+- No randomness. No LLM-generated scores without explicit numeric input.
+- No stacked multipliers. One Feasibility & Risk Gate only.
+
+---
+
+## 1. Diagnostic Dimension Categories (21 dimensions, each in exactly one category)
+
+Each dimension appears in exactly one category. Categories contribute to non-overlapping judging criteria.
+Category 6 (Criteria Alignment) is a validation layer — it does not add points.
+
+| # | Category | Dimensions | Primary Judging Criteria Mapped |
+|---|----------|------------|--------------------------------|
+| 1 | Problem & Solution | 1, 2, 3, 4, 5 | Problem significance, User value |
+| 2 | Innovation & Differentiation | 6, 7 | Innovation |
+| 3 | Technical Feasibility | 8, 9, 10 | Technical implementation |
+| 4 | Implementation Reality | 11, 12 | Feasibility, Team capability |
+| 5 | Demo & Presentation | 13, 14 | Demo quality, Presentation quality |
+| 6 | Criteria Alignment | 15 | All judging criteria (meta-validation) |
+| 7 | Impact & Market | 16, 17 | Potential impact, Business value |
+| 8 | Competition & Risk | 18, 19 | Differentiation context, Market opportunity |
+| 9 | Risk & Evidence | 20, 21 | Risk level, Score reliability |
+
+**Dimension 15 (Judging-criteria alignment)** is placed in Category 6 only. It produces a boolean check: "Do all category scores map to stated criteria?" If criteria are `UNKNOWN`, this check fails and overall confidence is lowered.
+
+---
+
+## 2. Dimension Definitions (1–10 scale unless noted)
+
+| # | Dimension | Scale | Meaning |
+|---|-----------|-------|---------|
+| 1 | Problem importance | 1–10 | How meaningful is the problem? |
+| 2 | Problem clarity | 1–10 | Is the problem well-defined? |
+| 3 | Target-user clarity | 1–10 | Who is the user, exactly? |
+| 4 | User pain | 1–10 | How painful is the problem for users? |
+| 5 | Solution usefulness | 1–10 | Does the solution actually help? |
+| 6 | Innovation | 1–10 | Is it novel? |
+| 7 | Differentiation | 1–10 | How different from competitors? |
+| 8 | Technical feasibility | 1–10 | Can it be built? (10 = high feasibility) |
+| 9 | AI/ML necessity | 1–10 | Is AI actually needed? (10 = essential, 1 = superficial) |
+| 10 | Implementation complexity | 1–10 | How complex to build? (10 = high complexity) |
+| 11 | Time required | 1–10 | How much time needed? (10 = maximum time) |
+| 12 | Team skill fit | 1–10 | Does the team have the skills? (10 = high fit) |
+| 13 | Demo potential | 1–10 | Is the demo compelling? |
+| 14 | Judge appeal | 1–10 | Will judges like it? |
+| 15 | Judging-criteria alignment | 1–10 | Do scores map to stated criteria? |
+| 16 | Scalability/potential | 1–10 | Growth potential beyond hackathon |
+| 17 | Real-world impact | 1–10 | Actual user value |
+| 18 | Competitive landscape | 1–10 | Less competition = higher score |
+| 19 | Defensibility | 1–10 | Hard to copy? |
+| 20 | Risk | 1–10 | **10 = highest risk** (penalty increases with score) |
+| 21 | Evidence quality | 1–10 | How well-backed are claims? |
+
+**Risk direction (dimension 20):** 1 = lowest risk, 10 = highest risk. Higher score = higher penalty.
+
+---
+
+## 3. Criterion-to-Category Mapping
+
+| Judging Criterion | Contributing Categories | Dimensions |
+|-------------------|------------------------|------------|
+| Problem significance | Problem & Solution | 1, 2, 4 |
+| User value | Problem & Solution | 3, 5 |
+| Innovation | Innovation & Differentiation | 6 |
+| Technical implementation | Technical Feasibility | 8, 9, 10 |
+| Feasibility / Team | Implementation Reality | 11, 12 |
+| Demo quality | Demo & Presentation | 13 |
+| Presentation quality | Demo & Presentation | 14 |
+| Criteria alignment | Criteria Alignment | 15 (validation only) |
+| Impact / potential | Impact & Market | 16, 17 |
+| Market opportunity | Competition & Risk | 18, 19 |
+| Risk adjustment | Risk & Evidence | 20, 21 |
+
+**No double-counting rule:** Each dimension appears in exactly one category. Each category contributes to non-overlapping judging criteria. Category 6 does not add points — it validates mapping.
+
+---
+
+## 4. Judging Criteria Weighting
+
+### When criteria and weights are known
+
+Use the hackathon's published judging criteria and weights as the primary scoring buckets:
+
+```
+raw_score = Σ(criterion_score_i × weight_i) / Σ(weight_i)
+```
+
+Where `criterion_score_i` is the weighted average of category scores mapped to that criterion.
+
+### When criteria/weights are UNKNOWN
+
+- Use equal weights across available categories
+- Set overall confidence flag = `low`
+- Explicitly state: "Judging criteria unknown; score based on equal-weight diagnostic assessment"
+- Do NOT present false precision
+
+---
+
+## 5. Feasibility & Risk Gate (single documented adjustment)
+
+The five feasibility/risk dimensions (8, 10, 11, 12, 20) already feed into categories 3, 4, and 9. Instead of applying separate multipliers on top, apply **one documented gate**:
+
+```
+feasibility_composite = avg(
+    dimension_8,                        // technical feasibility (10 = high feasibility)
+    (11 - dimension_10),                // implementation complexity inverted (10 = simple)
+    (11 - dimension_11),                // time required inverted (10 = fits in time)
+    dimension_12,                        // team skill fit (10 = high fit)
+    (11 - dimension_20)                 // risk inverted (10 = low risk)
+)
+```
+
+**Gate thresholds:**
+
+| Composite Range | Gate Result | Implication |
+|-----------------|-------------|-------------|
+| ≥ 6.0 | PASS | Idea can be SELECTed |
+| < 6.0 | FAIL | Idea cannot be SELECTed; must be REVISE or REJECT_ALL |
+
+**Rationale:** This is a single gate, not stacked multipliers. The five dimensions count once in their categories; the gate is a single feasibility threshold.
+
+---
+
+## 6. Final Score Formula
+
+```
+raw_score = weighted criterion average (0–100)
+final_score = raw_score × (feasibility_composite / 10)
+```
+
+The `(feasibility_composite / 10)` factor is the **only** multiplicative adjustment. No team_fit_factor, no time_pressure_factor, no separate risk_penalty. Those dimensions are already accounted for inside `feasibility_composite`.
+
+---
+
+## 7. Confidence Model
+
+| Factor | High Confidence | Medium Confidence | Low Confidence |
+|--------|----------------|-------------------|----------------|
+| Evidence quality (dim 21) | ≥ 8 | 5–7 | ≤ 4 |
+| Judging criteria known | Yes | Partial | UNKNOWN |
+| Dimension scores all filled | Yes | 1–2 missing | 3+ missing |
+
+**Overall confidence:** Lowest confidence across all factors.
+
+---
+
+## 8. Evidence Model
+
+Every research claim carries:
+
+| Field | Values |
+|-------|--------|
+| `type` | FACT | INFERENCE | ASSUMPTION | UNKNOWN |
+| `value` | The claim |
+| `source` | URL, file path, or "team input" |
+| `confidence` | low | medium | high |
+
+**Rules:**
+- No dimension score may be justified by `UNKNOWN` or `ASSUMPTION` without explicit flagging.
+- Never claim research was performed unless evidence was actually retrieved.
+- Separate FACT from INFERENCE from ASSUMPTION.
+
+---
+
+## 9. Red-Team Outcomes (Deterministic)
+
+| Outcome | Definition | Conditions |
+|---------|------------|------------|
+| **KILL** | Idea cannot be presented; fundamental flaw | (a) Feasibility gate FAIL with no credible revision path within time, OR (b) dimension_20 ≥ 9 AND dimension_8 ≤ 3, OR (c) dimension_9 ≤ 3 AND idea claims "AI-powered" (superficial AI) |
+| **MAJOR CONCERN** | Significant weakness, fixable | Any criterion-critical dimension scores 3–5, OR feasibility gate score 6.0–7.0 |
+| **MINOR CONCERN** | Cosmetic weakness | Any non-critical dimension scores 6–7 |
+
+**Not unnecessarily aggressive:** KILL requires either (a) feasibility gate failure with no revision path, or (b) simultaneous high risk + low feasibility, or (c) superficial AI claim. A single medium score does not trigger KILL.
+
+---
+
+## 10. Decision Outcomes
+
+| Outcome | Meaning | Effect on project-state.md |
+|---------|---------|---------------------------|
+| **SELECT** | One idea recommended | Writes to `.sherpa/decisions.md` only. Does NOT set `selected idea` |
+| **REVISE** | Ideas need modification | Writes revision plan to `.sherpa/decisions.md`. No change to `selected idea` |
+| **REJECT_ALL** | No candidate ideas viable | Writes rejection rationale to `.sherpa/decisions.md`. No change to `selected idea` |
+
+**Human authority:** Only explicit human confirmation can change `selected idea` in `.sherpa/project-state.md`.
+
+---
+
+## 11. Acceptance Test Definitions
+
+| Test | Expected Result |
+|------|----------------|
+| Missing dimension detection | Any dimension scored `UNKNOWN` is flagged; score carries low confidence |
+| Risk direction correctness | risk_dimension=10 produces higher penalty than risk_dimension=1 |
+| No double-counting | Each of 21 dimensions appears in exactly one category |
+| Known judging criteria | Score uses published weights; confidence not lowered for criteria |
+| Unknown judging criteria | Score uses equal weights; confidence flag = low; explicit note stated |
+| Human confirmation requirement | Engine never auto-sets `selected idea`; human must confirm explicitly |
+| REVISE loop | REVISE → weaknesses → changes → re-evaluate → new outcome supported |
+| Red-team kill conditions | KILL triggers only under defined conditions (gate failure, risk+feasibility, superficial AI) |
+| Exactly one primary next action | Output always contains exactly one PRIMARY NEXT ACTION |
+
+---
+
+## 12. Determinism Guarantee
+
+Two runs with identical:
+- Evidence (same FACT/INFERENCE/ASSUMPTION/UNKNOWN tags and sources)
+- Criteria and weights
+- Team capability (dimension 12)
+- Time remaining (dimension 11)
+
+…must produce identical scores and recommendations. No randomness. No LLM-generated numeric scores without explicit input.

package/skills/sherpa/rules/submission-rules.md

@@ -0,0 +1,41 @@
+# sherpa — Phase 19 Submission Rules
+
+**Lifecycle Phase:** Phase 19 — Submission Intelligence  
+**Operation:** `SUBMISSION-PREPARE`  
+**Purpose:** Discover, verify, and freeze a submission package. Phase 19 prepares; the human submits.
+
+## Authority and evidence
+
+Use sources in this order: official rules; official portal instructions; organizer communications; official judging criteria; explicit project requirements; project-specific instructions; user information; internal artifacts. Preserve conflicts, identify authority, and request human verification where needed. An undocumented requirement is not mandatory absent evidence.
+
+Classify evidence as FACT, INFERENCE, ASSUMPTION, or UNKNOWN. Each VERIFIED claim must cite its actual source and verification method. A file's existence does not prove its contents, accessibility, permissions, correctness, freshness, or format. UNKNOWN never becomes verified by inference. Do not use fabricated test, build, dependency, API, URL, access, submission, or deployment claims.
+
+## Requirement and status models
+
+Each requirement records ID, requirement, source, mandatory flag, evidence, artifact/field, status, owner, deadline, and notes. Status: VERIFIED, READY, MISSING, INVALID, BLOCKED, UNKNOWN, NOT_APPLICABLE.
+
+Deadline record: deadline, timezone, source, confidence, current status, time remaining. Deadline states: UPCOMING, URGENT, DUE_SOON, DEADLINE_PASSED, UNKNOWN. Never assume a timezone or invent a deadline.
+
+Artifact record: ID, name, type, location, version, required flag, accessibility, verification, last checked, hash/identifier, status. Field record: ID, field, required flag, value, source, evidence, character limit, format, status, notes. Unknown values stay UNKNOWN.
+
+Link states: VERIFIED_ACCESSIBLE, ACCESSIBLE_WITH_AUTH, BROKEN, REDIRECTED, UNKNOWN, NOT_APPLICABLE. Access states: PUBLIC, RESTRICTED, AUTH_REQUIRED, EXPIRED, UNKNOWN. Verify syntax, destination, expected content, permissions, authentication, and expiry when possible. Do not expose credentials or recommend public exposure of sensitive data.
+
+## Verification boundaries
+
+Inspect the actual repository and available package. Check repository/branch/intended commit, README and setup documentation, required files, links, accidental private data, debug artifacts, and configuration. Verify deployment, demo/video, PPT and file limits only when actual artifacts and authoritative requirements are available. Never imply setup works without executing it. Secret checks use bounded scope language: “No secret indicators were detected within the audited submission scope.”
+
+Keep submission form, README, PPT, demo, repository, deployment, project description, selected idea, and final audit claims consistent. Audit claims as VERIFIED, SUPPORTED, PARTIALLY_SUPPORTED, UNSUPPORTED, CONTRADICTED, UNKNOWN. Unsupported claims must be corrected or removed; contradicted claims must not be submitted; metrics require evidence.
+
+## Snapshot, freeze, and readiness
+
+Create a submission snapshot with snapshot ID, timestamp/timezone, repository commit, branch, frontend/backend/PPT/video/documentation versions, deployment URL, and status. Mark missing values UNKNOWN. After snapshot, classify changes REQUIRED, SAFE, RISKY, or FORBIDDEN_AFTER_FREEZE. Freeze is ACTIVE only after critical artifacts are verified; unresolved required unknowns prevent claiming complete verification. After freeze, only critical submission fixes, broken-link fixes, required metadata corrections, access fixes, and organizer-required changes are routine. Destructive changes, idea changes, major architecture changes, replacing the submission artifact, and scope changes require explicit human approval.
+
+Readiness values: NOT_READY, CONDITIONAL, BLOCKED, READY_TO_SUBMIT. READY_TO_SUBMIT requires all mandatory requirements verified, required artifacts and formats verified, links accessible, critical claims supported, no unresolved critical blockers, a consistent package and final snapshot, deadline known or explicitly verified, and human confirmation still pending. Framework validation alone never yields live READY_TO_SUBMIT. Human submission remains external and unchecked.
+
+Each risk records ID, description, severity, likelihood, confidence, impact, mitigation, owner, status. Keep severity and confidence separate. Critical risk blocks READY unless VERIFIED_MITIGATED or ACCEPTED_RISK with human authority.
+
+## Human control and prohibited operations
+
+Always surface `FINAL HUMAN CONFIRMATION REQUIRED` before the eventual human submission, including package, destination, deadline/timezone, risks, snapshot, unresolved noncritical issues, and irreversible consequences. The system must NEVER click a final submit button, submit a form or entry, publish private information, change repository visibility, upload to the portal, or accept irreversible terms. It never performs the actual submission. The final checklist item “Submission performed” remains unchecked in Phase 19.
+
+Do not develop features, redesign architecture/demo/PPT/final audit, change the selected idea, perform post-mortem, install dependencies, deploy, or modify application code. Preserve locked Phase 1–18 behavior and exactly one `PRIMARY NEXT ACTION`.