# Step 2: Patent Point Mining (Three-Element Test)

## MANDATORY EXECUTION RULES (READ FIRST)

- 📖 **You MUST read `references/mining-principles.md` in full before proposing candidates.** It is the authoritative source for the three-element test, negative/positive examples, and common pitfalls. When this file conflicts with anything in this step, the reference wins.
- 🛑 Do NOT write any disclosure prose in this step. Output is a candidate list only.
- ✅ Be willing to return zero candidates if nothing passes the test. Quality > quantity.
- ⏸️  HALT at the end of this step. Do not proceed to step-03 until the user has explicitly selected which candidates to write up AND supplied inventor info.

## YOUR TASK

For every plausible lead from the step-01 memo, apply the three-element test and produce a candidate list with prioritization.

## EXECUTION SEQUENCE

### 2.1 Three-element formula (per candidate)

For each candidate, fill three slots:

```
Because (technical problem)
 → using (technical means)
 → result (technical effect, with numbers if possible)
```

If any slot is vague, missing, or non-technical, the candidate **fails** — drop it or sharpen it before re-testing.

### 2.2 Hard exclusions (quick reject)

Anything that matches the following is **not** patentable software subject matter:

- Generic business need / non-technical problem / vague description
- Non-technical means, simple combinations of existing techniques, pure intellectual/management rules
- Only commercial benefit, operational gain, or subjective UX improvement
- Pure code / pure formula / pure algorithm on paper → goes to software copyright
- Standard usage of open-source frameworks (Spring/Django/Express defaults, ORM CRUD, etc.)
- Plain CRUD
- Routine application of well-known design patterns (Singleton, Strategy, Observer used in textbook fashion)

See `references/mining-principles.md` for the worked counter-examples.

### 2.3 High-value directions (where inventions usually live)

- **Architecture:** novel service decomposition / aggregation, self-built service-governance mechanisms, multi-source consistency under specific constraints, scenario-specific caching topology
- **Algorithms:** business rule engine internals, custom data matching/validation, complex query optimization, state-machine flow control
- **Process:** multi-step approval orchestration, async scheduling with compensation, cross-system sync, sharded parallel batch
- **Reliability:** encryption/masking schemes, distributed locking variants, idempotency, disaster recovery and failover

### 2.4 Candidate list output

Present to the user in this exact shape:

```
候选专利点 / Candidate Patent Points

1. [Title — one sentence]
   - Module / code path: ...
   - 技术问题 / problem: ...
   - 技术手段 / means: ...
   - 技术效果 / effect (with numbers): ...
   - 建议优先级 / priority: H/M/L
   - 备注 / notes: (e.g., similar prior art X to differentiate from)

2. ...
```

### 2.5 Collect inventor metadata

For each of the four fields below, if the user pre-set a value in `{project-root}/_xiaoma/xpm/config.yaml` use it as a default; otherwise prompt fresh. Record the final answers as session variables for use in step-03:

- `inventor_name` — Inventor name(s)
- `inventor_contact_name` — Patent contact person
- `inventor_contact_phone` — Contact phone
- `inventor_contact_email` — Contact email
- Any confidentiality / disclosure restrictions (free-form, not a config key)

## HALT

Stop here. Ask:

> "I have listed N candidate points above. Which numbers do you want me to write up as disclosures? (You can pick 1+ or ask me to refine specific points before proceeding.)"

Wait for explicit selection before loading step-03.

## NEXT STEP

After the user selects candidates and supplies inventor info, load `./step-03-disclosure-writing.md` once per selected candidate.