Problem
PR #97 introduced a new hasKeyword helper in packages/core/src/archetypes/index.ts that uses regex word boundaries instead of text.includes. This is a correctness fix (e.g. swift no longer matches swiftly, go no longer matches go-to-market), but it silently changes detection behavior for every existing archetype, not just the new mobile one.
Today there are no regression tests pinning down what each existing archetype should detect, so:
- If a borderline resume was previously being scored correctly by a partial-match side effect, that signal is now gone and detection may flip to a different archetype.
- If a future change touches
hasKeyword or the detector loop, there's no safety net to catch a regression in any archetype other than mobile-engineer.
The mobile-engineer detection tests added in PR #97 are a good template; this issue asks for the same coverage across the rest.
Proposed solution
Add a describe block per existing archetype in packages/core/src/__tests__/archetypes.test.ts (or split into per-archetype files if the file gets unwieldy), each with at minimum:
- One realistic positive test — a 2-3 sentence resume that should detect as that archetype. Use the real mix of keywords the role would actually use.
- One realistic negative test — a resume from an adjacent role that should NOT detect as this archetype (mirrors the
swift/swiftly case the PR added for mobile).
- One structural validation test — archetype is registered, has the documented keyword/verb/anti-pattern counts, weights sum to 1.0 (mirroring the assertions in the new mobile-engineer block).
Archetypes to cover:
ai-product-managerai-engineerbackend-engineerfrontend-engineerqa-test-engineerdevops-sredata-engineer
Mirror the structural assertions in packages/intelligence/src/__tests__/intelligence.test.ts for the intelligence registry so both packages stay aligned — that drift is the explicit pain point tracked in docs/ARCHETYPE_GAP_AUDIT.md.
Alternatives considered
- Snapshot a single end-to-end fixture per archetype: cheaper but less precise; a future keyword list change would update the snapshot instead of failing it.
- Defer entirely: leaves the boundary change unverified; the next detector bug will be caught by users, not tests.
Additional context
Problem
PR #97 introduced a new
hasKeywordhelper inpackages/core/src/archetypes/index.tsthat uses regex word boundaries instead oftext.includes. This is a correctness fix (e.g.swiftno longer matchesswiftly,gono longer matchesgo-to-market), but it silently changes detection behavior for every existing archetype, not just the new mobile one.Today there are no regression tests pinning down what each existing archetype should detect, so:
hasKeywordor the detector loop, there's no safety net to catch a regression in any archetype other thanmobile-engineer.The mobile-engineer detection tests added in PR #97 are a good template; this issue asks for the same coverage across the rest.
Proposed solution
Add a
describeblock per existing archetype inpackages/core/src/__tests__/archetypes.test.ts(or split into per-archetype files if the file gets unwieldy), each with at minimum:swift/swiftlycase the PR added for mobile).Archetypes to cover:
ai-product-managerai-engineerbackend-engineerfrontend-engineerqa-test-engineerdevops-sredata-engineerMirror the structural assertions in
packages/intelligence/src/__tests__/intelligence.test.tsfor the intelligence registry so both packages stay aligned — that drift is the explicit pain point tracked indocs/ARCHETYPE_GAP_AUDIT.md.Alternatives considered
Additional context
packages/core/src/__tests__/archetypes.test.tslines 1-49 (mobile-engineer suite) andpackages/intelligence/src/__tests__/intelligence.test.tslines 37-54.docs/ARCHETYPE_GAP_AUDIT.md.