nx_skill_request.nx

nx_skill_request.nx -- LIB: "my chef hasn't covered this -- ask them." Requests as a DEMAND INSTRUMENT. The estate already banked the rule this is built on: MEASURE demand, never predict desirability, and DUPLICATE COUNT IS POPULARITY -- it is free and already computed. So a request is not a wish list entry, it is a counted signal, and the count is what a chef is actually shown when deciding what to film next. THREE THINGS IT REFUSES TO DO, because each one would corrupt the signal it exists to produce: 1. IT WILL NOT COUNT THE SAME PERSON TWICE. Demand is DISTINCT requesters, not clicks. One enthusiast hitting the button ten times is one person who wants it; counting clicks would let a single loud user outrank a genuinely popular gap, which is precisely the failure mode that makes vote counts worthless. 2. IT WILL NOT REQUEST WHAT ALREADY EXISTS. If the chef has already covered that skill, the request is REFUSED and the existing video is handed back instead. Sending someone a request for work they have already done wastes their goodwill and teaches them to ignore the channel. 3. IT WILL NOT TREAT "WE NEVER INDEXED THEM" AS "THEY HAVEN'T DONE IT." A request against a chef we do not hold is accepted but TAGGED as un-indexed, so it routes to our own crawling backlog rather than to a chef who may already have the video sitting on their channel. Schema (prefix passed in, e.g. knowledge/store/skillreq-): req:ids -> TAB list of request keys req:<chef>:<skill> -> distinct-requester count <t> kind <t> chef-indexed(1|0) reqby:<chef>:<skill> -> TAB list of unit ids that asked (the dedup set AND the audit trail) license_tier: ORIGINAL No hw writes (Rule 26).