diff --git a/docs/discovery/open-questions.md b/docs/discovery/open-questions.md index 24756a4..e5d573c 100644 --- a/docs/discovery/open-questions.md +++ b/docs/discovery/open-questions.md @@ -60,12 +60,12 @@ Found while checking every page against `init.docx`. Each item is behavior that | ID | Pri | Brief section | Question | Current behavior (evidence) | Owner | Answer | | ---- | --- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------- | --------------------------------------- | -| Q-35 | P1 | §3.3 | The brief asks for an **improved JD draft**. Build a whole-document improved JD, or approve the current approach (accepted benchmark suggestions become edits of the structured JD)? | Accepted suggestions are applied as edits to the structured JD. The AI purpose `jd.improve` (`apps/web/src/server/ai/purposes.ts`) and artifact kind `improved_jd` (`packages/core/src/artifacts/kinds.ts`) exist but are unused stubs. | Product owner | Needs product owner confirmation (open) | -| Q-36 | P1 | §1.1 | "AI runs only on request": resume upload, bulk upload and CSV intake **automatically enqueue `profile.structure`**, and the daily `embeddings.catch_up` job sends approved profiles (stripped of name and contact details) to Voyage AI without a per-run user action. Keep as intake-time processing, or require a request? | Worker handlers index and `apps/web/src/server/candidates/intake.ts` enqueue structuring on intake. The result stays a draft until a recruiter approves it. Embeddings run daily for approved profiles only. | Product owner | Needs product owner confirmation (open) | -| Q-37 | P2 | §9.2 | The brief describes approval of the resume and the profile. Today **one Approval row covers both**. Should the profile get its own approval record? | `ApprovalSubject.candidate_profile` exists but is unused. | Product owner | Needs product owner confirmation (open) | -| Q-38 | P2 | §4.3 | The portfolio check should cover which positions? Today it scores **only open positions that have an approved success profile**; other open positions are skipped. | Positions without an approved success profile do not appear in the portfolio check. | Product owner | Needs product owner confirmation (open) | -| Q-39 | P2 | §1.1 | The performance metric in the brief is time per candidate. The product reports **positions per recruiter and median active days per position**. Confirm the metric, or add time per candidate? | Analytics shows positions per recruiter and median active days per position. | Product owner | Needs product owner confirmation (open) | -| Q-40 | P1 | UI language | **Korean UI**: 17 of the 19 `messages/ko` catalogs are empty (documented in ADR-015 and Q-08). Does release 1 need Korean, or is English-only acceptable until the Korea phase? | The English catalogs are complete; Korean falls back to English. | Product owner | Needs product owner confirmation (open) | +| Q-35 | P1 | §3.3 | The brief asks for an **improved JD draft**. Build a whole-document improved JD, or approve the current approach (accepted benchmark suggestions become edits of the structured JD)? | Accepted suggestions are applied as edits to the structured JD. The AI purpose `jd.improve` (`apps/web/src/server/ai/purposes.ts`) and artifact kind `improved_jd` (`packages/core/src/artifacts/kinds.ts`) exist but are unused stubs. | Product owner | **Approve the current approach for release 1.** Accepted benchmark suggestions become edits of the structured JD; no whole-document improved JD. Remove or keep the `jd.improve` / `improved_jd` stubs out of the UI. Revisit if agencies ask for a one-click rewrite. (Answered by Claude on Peter Jung's instruction, 2026-10-09; confirm.) | +| Q-36 | P1 | §1.1 | "AI runs only on request": resume upload, bulk upload and CSV intake **automatically enqueue `profile.structure`**, and the daily `embeddings.catch_up` job sends approved profiles (stripped of name and contact details) to Voyage AI without a per-run user action. Keep as intake-time processing, or require a request? | Worker handlers index and `apps/web/src/server/candidates/intake.ts` enqueue structuring on intake. The result stays a draft until a recruiter approves it. Embeddings run daily for approved profiles only. | Product owner | **Keep intake-time structuring; uploading is the request.** The recruiter's upload, bulk upload or CSV import is the explicit action, and the result stays a draft until approved. **Embeddings:** keep the daily catch-up for approved profiles only (name and contact stripped), and state it in the privacy help; follow-up: add an agency setting to turn it off. (Answered by Claude on Peter Jung's instruction, 2026-10-09; confirm.) | +| Q-37 | P2 | §9.2 | The brief describes approval of the resume and the profile. Today **one Approval row covers both**. Should the profile get its own approval record? | `ApprovalSubject.candidate_profile` exists but is unused. | Product owner | **One Approval covering resume and profile is acceptable for release 1.** The audit trail must record both subjects. A separate profile approval is a later change if agencies need it. (Answered by Claude on Peter Jung's instruction, 2026-10-09; confirm.) | +| Q-38 | P2 | §4.3 | The portfolio check should cover which positions? Today it scores **only open positions that have an approved success profile**; other open positions are skipped. | Positions without an approved success profile do not appear in the portfolio check. | Product owner | **Keep scoring only open positions with an approved success profile**, but list the skipped open positions with the reason ("needs an approved success profile") instead of hiding them. Follow-up UI change. (Answered by Claude on Peter Jung's instruction, 2026-10-09; confirm.) | +| Q-39 | P2 | §1.1 | The performance metric in the brief is time per candidate. The product reports **positions per recruiter and median active days per position**. Confirm the metric, or add time per candidate? | Analytics shows positions per recruiter and median active days per position. | Product owner | **Keep positions per recruiter and median active days per position for release 1; add time per candidate later** once task and stage timestamps are reliable. (Answered by Claude on Peter Jung's instruction, 2026-10-09; confirm.) | +| Q-40 | P1 | UI language | **Korean UI**: 17 of the 19 `messages/ko` catalogs are empty (documented in ADR-015 and Q-08). Does release 1 need Korean, or is English-only acceptable until the Korea phase? | The English catalogs are complete; Korean falls back to English. | Product owner | **English-only is acceptable for release 1** (U.S. first, per Q-07). Korean catalogs follow in the Korea phase (ADR-015, Q-08); Korean falls back to English until then. (Answered by Claude on Peter Jung's instruction, 2026-10-09; confirm.) | ## Decisions log @@ -85,6 +85,12 @@ Found while checking every page against `init.docx`. Each item is behavior that | 2026-10-06 | Add a **`/admin` section for platform administrators** (Team of Wakers staff): agencies, platform admins, usage and budgets, audit log in release 1; support access, billing, tenant lifecycle, system health and configuration in release 2 (FR-ADM-01…10) | Product owner | | 2026-10-06 | First customer (tenant #1) is **Team of Wakers' internal use** (Q-29). PopResume approved for the evaluation set, subject to Hugging Face access approval | Product owner | | 2026-10-06 | **All ADRs 001–017 accepted**; Interactor auth like product-manager (Q-32); Sonnet 5.5 for high-volume AI purposes (Q-33); Voyage OK, no userdb (Q-34) | Product owner | +| 2026-10-09 | **Q-35** answered on Peter Jung's instruction by Claude (to be confirmed by the product owner): Approve the current approach for release 1. Accepted benchmark suggestions become edits of the structured JD; no whole-document improved JD. Remove or keep the `jd.improve` / `improved_jd` stubs out of the UI. Revisit if agencies ask for a one-click rewrite. | +| 2026-10-09 | **Q-36** answered on Peter Jung's instruction by Claude (to be confirmed by the product owner): Keep intake-time structuring; uploading is the request. The recruiter's upload, bulk upload or CSV import is the explicit action, and the result stays a draft until approved. Embeddings: keep the daily catch-up for approved profiles only (name and contact stripped), and state it in the privacy help; follow-up: add an agency setting to turn it off. | +| 2026-10-09 | **Q-37** answered on Peter Jung's instruction by Claude (to be confirmed by the product owner): One Approval covering resume and profile is acceptable for release 1. The audit trail must record both subjects. A separate profile approval is a later change if agencies need it. | +| 2026-10-09 | **Q-38** answered on Peter Jung's instruction by Claude (to be confirmed by the product owner): Keep scoring only open positions with an approved success profile, but list the skipped open positions with the reason ("needs an approved success profile") instead of hiding them. Follow-up UI change. | +| 2026-10-09 | **Q-39** answered on Peter Jung's instruction by Claude (to be confirmed by the product owner): Keep positions per recruiter and median active days per position for release 1; add time per candidate later once task and stage timestamps are reliable. | +| 2026-10-09 | **Q-40** answered on Peter Jung's instruction by Claude (to be confirmed by the product owner): English-only is acceptable for release 1 (U.S. first, per Q-07). Korean catalogs follow in the Korea phase (ADR-015, Q-08); Korean falls back to English until then. | ## Change record: 2026-10-06 P0 answers