rob → elazar: Coder says the multi-select code looks correct (Set+toggle). Two interpretations: (a) real bug where clicking selects all/none, or (b) UX mismatch — client expects single-select (picking comuna 3 should replace comuna 5, not stack). Which is the actual behavior the client saw? A screenshot/video helps. Same question applies to WI 279 (comunas).

rob → elazar: Title 'Conversación se actualice cada 24hs' is ambiguous. Two interpretations: (A) DATA reset: events.message field gets cleared after 24h via cron (mirrors existing reset-comida pattern at app/src/app/api/cron/reset-comida/route.ts). Use case: forces fresh conversación on each visit older than 24h. (B) UI refresh: client-side polling/revalidation that re-fetches the necesidad detail every 24h. Low value — user would have closed tab. Which does the client mean? If (A), what's the target field exactly: events.message, or something else? Hard cut to NULL or to a default value?

rob → elazar: Which comisión should each of the 3 unassigned teachers be assigned to? gonzalo.oviedo, lorena.salomone, cirugia1 (@odontologia.uba.ar). Need comisión name/id + role (adjunto/jtp) for each.

rob → elazar: memory-lint enforces evolutiva-memory-discipline.md across ALL ~/.claude/projects/*/memory dirs, but two of its rules collide with the global CLAUDE.md and produce hard-fails on memories that exist by direct instruction. Need Elazar to pick. CONFLICT 1 - per-agent identity (§12): §12 bans per-agent identity (ARO membership, post-compact reattach, agent name) from memory/. But global CLAUDE.md ss-protocol explicitly says 'carry over agent name + AROs (write to memory file)'. session-identity.md exists by that instruction and hard-fails §12. Options: (A) §12 carves an exception for ONE fixed-name file (e.g. session-identity.md) allowed to hold agent name + AROs; (B) ss-protocol moves identity out of memory/ into a sibling dir memory-lint does not scan (e.g. .role/). CONFLICT 2 - dates (§9): §9 bans YYYY-MM-DD dates as 'dynamic content'. But feedback/reference memories legitimately cite dates as historical provenance (when Elazar gave a rule, when a fact was verified) - not as 'as of' staleness stamps. feedback-channel-discipline.md and feedback-verify-before-relaying.md hard-fail on this. Options: (A) §9 allows dates in feedback/reference type memories when used as event provenance; (B) keep the ban - memories must cite events/WI ids instead of literal dates. Recommend 1(A) + 2(A): both are one-line carve-outs to the discipline doc, vs. relocating files / stripping provenance. Pick per conflict.

rob → elazar: bwi git-sync policy: whey-only (venus agents route through whey-based basquetWi-cc) OR resume committing+pushing canonical DB to GitHub so all hosts can git pull? venus host had stale DB since 2026-05-06; pm-venus-cc confirmed via git pull that GitHub remote is also stale at that date.

rob → elazar: bin-whey-cc gates outward GitHub pushes on a DIRECT Elazar word (not a PM relay). The commons §Email Identity codification commit (shared/md/evolutiva-commons.md, the regression-guard for the fleet gmail-dedup — all 3 apps ALREADY enforce dedup at the DB, this just writes the rule so a future app can't reintroduce the bug) needs your explicit push-approval delivered to bin DIRECTLY: your CLI word, or a from=elazar DM to bin-whey-cc. Approve the commons --minor push?

wi-cli-whey → elazar: kpi.pensanta.com exposure: public subdomain (DNS + nginx/caddy TLS, like a normal pensanta site) or Tailscale-only/localhost? chat-duo-web's model — confirm which. Drives security posture (read-only telemetry, but still your KPI data).

wi-cli-whey → elazar: one-db source dir ~/Documents/terminal/one-db (schema.sql/00-role.sh/backfill.sh — not PATH scripts): make it its own git repo, or leave untracked working files? (still-open Q from before compact)

wi-cli-whey → elazar: ONEDB-10 venus-kpi pg-flip is a fork decision, not a mechanical edit. venus-kpi-collect.sh is a stale BUGGY fork of kpi-enforce.sh (the canonical whey collector that already does keep-sqlite+pg-mirror correctly and fixed the FK/rowid + dead-DM bugs the venus script still has). Pick: (A) port just the mirror pattern into venus-kpi-collect.sh — minimal, but keeps a 2nd buggy script alive (its FK/dead-DM bugs need fixing anyway = scope creep); or (B) make kpi-enforce.sh host-aware (whey: memory_lint+backup_whey / venus: memory_lint+disk+systemd, gated on HOST), RETIRE venus-kpi-collect.sh, venus runs the canonical script. One collector, buggy fork dies, pg-mirror free. Touches whey's live collector. I recommend B. host col namespaces rows so no double-count either way.

wi-cli-venus → elazar: What counts as 'routine enough to batch into a daily digest' vs 'push to me directly now'? Proposed carve-outs that stay DIRECT regardless: (a) triage-loop pre-analyzed verdicts (access grants, support-ticket dispositions), (b) live-ticket/incident coordination, (c) anything blocked-on-you. Candidate-to-batch: FINISHED banners, deploy/PASS notices, non-blocking status. Holding all pm-pluto-cc->Elazar throttling until you rule.

wi-cli-venus → nw-venus-cc: clamav on venus: resurrect clamav-scan.sh (git-restore from before bb35245) at monthly cadence, or leave it removed per the 2026-07-06 'uninstalled fleet-wide' directive? Package (apt clamav/clamav-freshclam) is still installed either way -- that part was never actually done despite the commit message.