Closes #2787: emit no-response-friction signal per RFC #1506 schema v1 - #2788

sequenceDiagram
  participant Operator
  participant CompanyHistory
  participant SignalBuilder
  participant Output
  Operator->>CompanyHistory: run with --summary --emit-signal
  CompanyHistory->>SignalBuilder: buildNoResponseFrictionSignals(result, opts)
  SignalBuilder-->>CompanyHistory: schema-v1 signal records
  CompanyHistory->>Output: write normal output
  CompanyHistory->>Output: append JSON Lines signals

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Pushed a follow-up commit (eae2675) addressing all 4 CodeRabbit findings.

1. observedAt/sourceHash instability (Major) — silentFactObservedAt() now anchors on fact.appliedDate's own month directly instead of appliedDate + silenceWindowDays. Since --silence-window is configurable, the old version could shift observedAt (and therefore sourceHash) for the same underlying silent fact depending on what window was in effect on a given run, which breaks dedup. Dropped the now-unused silenceWindowDays parameter and updated the call site + comment accordingly.

2. severity/anchor diverged from the label computation (Major) — Two related fixes in buildNoResponseFrictionSignals:

• Stale facts are now filtered out of severity the same way computeResponsiveness() excludes them from the silent-on-you label (unless --include-stale is passed). Threaded a new opts.includeStale through the function; the CLI call site now passes its own parsed includeStale value.
• The anchor fact is now chosen by comparing appliedDate strings (lexicographic, which works for ISO dates) instead of tracker row num — a backfilled/out-of-order row could previously anchor on an older application despite carrying a larger row number.
• Added a self-test fixture with one active + one stale silent fact confirming severity stays 'single' (matching what the label actually reflects), plus an out-of-order appliedDate fixture confirming the anchor is chosen correctly.

3. Missing self-test coverage (Trivial) — Added assertions for:

• silentFactObservedAt returning null → buildNoResponseFrictionSignals skips that card entirely (no record, no crash).
• resolveRegion mapping an unmapped country to unmapped/<slug>, plus a companion assertion for a mapped country going through COUNTRY_REGION_MAP normally (exercising both branches and slugify).

4. --emit-signal mixed two output formats on stdout (Trivial) — Without --summary/--company, --emit-signal used to print a pretty-printed JSON document followed by appended JSON Lines records, breaking single-value JSON parsing of stdout. --emit-signal now requires --summary and rejects --company (both of those already print a single JSON document); parseArgs() fails fast with a clear error otherwise. Documented the contract in the USAGE block.

Test results:

• node company-history.mjs --self-test: 74 passed, 0 failed
• node company-history.test.mjs: 87 passed, 0 failed
• node test-all.mjs --quick: 3663 passed, 0 failed (1 pre-existing warning, unrelated to this file — portal-scanner truncation notices / CV-sync fixtures)

Addressed both findings from the second CodeRabbit round in 498d844:

Finding 1 — --emit-signal=<value> silently accepted
The unknown-flag check stripped an =value suffix before matching against KNOWN_FLAGS, so --emit-signal=true passed validation. But emitSignal was set via an exact-token check (args.includes('--emit-signal')), which is false for --emit-signal=true — so the flag was accepted as "known" yet the signal was never actually turned on. Added an explicit check that rejects any --emit-signal=... form with Error: --emit-signal does not accept a value. and exit 1. Covered by a new CLI smoke test in company-history.test.mjs (--emit-signal=true, --emit-signal=1, --emit-signal=).

Finding 2 — observedAt not trimmed before slicing
silentFactObservedAt() validated fact.appliedDate through parseDate() (which tolerates surrounding whitespace) but then sliced the raw, untrimmed string. A whitespace-padded appliedDate (e.g. ' 2026-06-01 ') would pass validation but slice to a malformed observedAt (leading space, wrong characters) instead of '2026-06' — breaking the schema's required YYYY-MM format and shifting sourceHash. Now trims before slicing. Covered by a new case in --self-test.

Verification:

• node company-history.mjs --self-test — 75 passed, 0 failed
• node company-history.test.mjs — 90 passed, 0 failed
• node test-all.mjs --quick — 3663 passed, 0 failed (1 pre-existing, unrelated warning: Node's SQLite experimental-feature notice)

Pushed to feat/no-response-friction-signal.

Slow first reply, @Schlaflied — sorry, and thanks for the patience. This one I read closely, and there's a detail in it I want to name because most people would have shipped past it:

// `--emit-signal=true` passes the unknown-flag check silently, but the boolean
// read is an exact-token args.includes('--emit-signal'), which is false for it
// — so the flag would be ACCEPTED and nothing would be emitted.

A typo that produces exit 0 and no output is the worst possible shape for this feature, because the absence of records is indistinguishable from "no company matched". Someone would conclude their tracker has no responsiveness signal in it. You caught a failure mode that only exists in the seam between two correct pieces, and closed it by failing loudly.

The other thing I checked before anything else: --emit-signal writes JSON Lines to stdout and nothing else. No fetch, no upload, no endpoint. That matters more than it might look — a record carrying companyKey, region and sourceHash is shaped like something that could travel, and the difference between "computes a shareable record locally" and "shares it" is the whole ballgame in this project. Local, opt-in behind a flag, printed for the user to look at, is the correct answer and I'm glad it's the one you picked without being asked.

Implementing a ratified RFC signal by wiring up a fact company-history.mjs already computes is also the right economy: the raw signal existed since #1712, and what was missing was the schema, not the analysis.

Where it stands: approved on my side, not merged tonight — I've hit the per-session merge ceiling I hold myself to, so the tail of the queue rolls to the next cycle rather than riding on end-of-session judgement. This is near the top when I pick it back up, and it isn't blocked on Santiago the way #2791 is: it touches company-history.mjs and its test, nothing critical.

@artemtrofymenko Thank you for this — running it against a real tracker instead of just reading the diff is exactly how #2 got caught, and I don't think I'd have found it from the diff alone. All three addressed:

1. sourceHash no longer includes severity (the blocking one). You're right that this breaks dedup: the same company-month fact can legitimately go single → pattern as more applications go silent, and hashing severity in made that one fact produce two different hashes depending on when it was emitted. computeSourceHash is now keyed on signalType|companyKey|observedAt only, so companyKey|observedAt is the stable identity and a later emission with updated severity is meant to represent an update to that identity, not a phantom duplicate. Added a self-test using your exact scenario — a 1-application and a 2-application fixture for the same company/month now produce the same sourceHash despite single vs pattern severity.

2. Full 10-field schema v1 now emitted. Added schemaVersion (1), detail, sourceDetector. On your two open questions:

• sourceDetector enum value: no-response-friction. The RFC thread only names interview-redflag and process-friction, so I'm establishing this as the third value here rather than finding it pre-named anywhere — flagging that explicitly since you asked. I went with no-response-friction (matching the signal's own signalType) because that's the existing convention in this schema already: sourceDetector == signalType for a detector that only emits one signal type. Happy to reconcile if a different value gets picked when a fourth detector shows up.
• detail: null, deliberate. This signal is derived purely from tracker dates (application date vs. silence window) — there's no free text anywhere in the pipeline it could carry, unlike e.g. process-friction's "interviewer no-show, no reschedule notice" example in the RFC. null felt more honest than inventing a fixed derived phrase that would just restate severity/observedAt in prose. Wasn't deliberate trimming before — it was a real gap, now closed, and I added a line in the RFC thread's spirit here rather than silently fixing it.

3. region: "unknown" replaced with skip-and-warn. resolveRegion() now returns null (not the string "unknown") when it can't resolve a region from config/profile.yml, and buildNoResponseFrictionSignals() skips emission for the affected company with a warning (region could not be resolved from config/profile.yml — signal not emitted for {companyKey}) instead of fabricating a value that would imply a real unknown/ directory in the shared-layer's region-scoped layout. This only skips the specific record — it doesn't error out the whole command over one unresolvable field. Added self-test coverage for the skip-with-warning path.

All landed in 56d7b6d, pushed to this branch. Self-tests: node company-history.mjs --self-test 84/84, node company-history.test.mjs 90/90, full node test-all.mjs --quick 3663 passed / 0 failed. Let me know if the sourceDetector naming choice looks wrong from where you're sitting — genuinely undecided territory since the RFC didn't cover it.

Update: a follow-up review caught one more spot with the same untrimmed-whitespace class of bug — the anchor-selection comparison in the silentFacts.reduce() above also needed a .trim() on both sides before comparing appliedDate strings, for the same reason silentFactObservedAt did earlier in this thread. Fixed and pushed in 22b8668 (new regression test: a whitespace-padded but more-recent date still wins the anchor over a clean-but-older one). Full suite still green: node company-history.mjs --self-test 85/85, node test-all.mjs --quick 3663 passed / 0 failed.

Addressed the 3 findings from the latest CodeRabbit review (the one reviewing 56d7b6d..22b8668 — the other review in this thread was against a stale commit range and re-flagged an already-fixed issue, no action needed there):

1. Minor, real bug: silentFacts filtered out unusable-appliedDate facts only implicitly (via the anchor's observedAt check), not before anchor selection/severity counting. A malformed date could win the lexicographic reduce, or even losing the reduce could still inflate severity to pattern. Now filtered via silentFactObservedAt(f) !== null before either step. New test: a card with one valid + one malformed fact emits exactly one record, anchors on the valid fact, and reports severity: 'single'.
2. Trivial, test gap: includeStale: true is now exercised end-to-end through buildNoResponseFrictionSignals (previously only the default-exclusion path was tested at that level) — confirms severity correctly flips to 'pattern' when the stale fact is included.
3. Trivial, test gap: added fixtures proving sourceHash actually differs when companyKey differs (same month) and when observedAt differs (same company) — the existing determinism test proved repeatability but not that the hash is sensitive to its own stated identity inputs.

node company-history.mjs --self-test: 91/91. node test-all.mjs --quick: 3663 passed, 0 failed.

sourceDetector — I land on company-history, though the honest starting point is that the existing enum does not settle it either way.

When you introduced the field you wrote:

Added sourceDetector. This schema now needs to represent output from both #1233 (interview-redflag) and #1467 (process-quality), so a record needs to say which one produced it — otherwise there's no way to trace provenance once both tools are emitting into the same format.

The two producers are named there as tools — interview-redflag and process-quality — but the enum as written is interview-redflag | process-friction. So one value is a tool name and the other is a signal name that differs from its own tool. There is no convention to follow; there are two precedents pointing in different directions.

That leaves the field's stated purpose as the tiebreak, and it is explicit: which one produced it. The producer here is company-history.mjs.

Two things push the same way. interview-redflag emits four signal types by the RFC's own enum — scope-ambiguity, defensive-closure, evaluator-competency-gap, process-signal — and is named after none of them, so the one precedent where a detector has more than one output already resolves as the tool. And company-history.mjs computes two independent axes today; if a second tracker-derived signal ever lands there, no-response-friction as a detector name is either wrong for it or needs renaming, and renaming an enum value already present in emitted records is the expensive kind of change. company-history stays correct however many signals the script grows.

Weak preference, not a blocker — you asked where I land, and that is where. Either value traces provenance adequately for the two detectors that exist today.

Verified on edd8d16: all ten fields present, schemaVersion: 1, detail: null; the 1-application and 2-application fixtures for the same company-month now produce the same sourceHash while severity still moves single → pattern; a different company and a different month each still produce a different hash; resolveRegion gives north-america/canada for a mapped country and unmapped/spain for an unmapped one, keeping the two-level shape the layout expects rather than flattening it. Self-tests 91/91, company-history.test.mjs 90/90.

One correction to my own earlier framing, since I raised it: I checked whether skip-and-warn leaves the feature silent on a default install, and it does not — location.country ships uncommented in profile.example.yml. The empty output I saw first was my sandbox having no config/profile.yml at all, not the fix.

@artemtrofymenko Thanks for the reasoning on sourceDetector — the interview-redflag.mjs precedent (tool name, not signal name, even across its 4 signal types) settles it, and you're right that renaming this cheaply now beats discovering the same argument later after real records exist with the old value.

Renamed sourceDetector from 'no-response-friction' to 'company-history' everywhere — the emission code, the self-test assertion, and the schema-shape comment (now explains the tool-name-not-signal-name reasoning and the future-proofing against postingChurn eventually feeding a second signal type).

node company-history.mjs --self-test: 91/91. node test-all.mjs --quick: 3663 passed, 0 failed.

Also appreciated the independent re-verification pass on edd8d16 — good catch on your own earlier framing too (the skip-and-warn silence was your sandbox missing config/profile.yml, not the fix).

Clean schema work, @Schlaflied: the REQUIRES --summary reasoning (keeping stdout parsable as one JSON value in default mode), the loud rejection of --emit-signal=value instead of silently emitting nothing, and region resolution tested against mapped/unmapped/absent profiles. First real producer of the #1506 schema in the tree. Merged 🚀