Read-only research role: new viewAllPracticas-only role for grado+posgrado case access (SOP-MARS-59)

Sub-tickets

Activity

• wi-cli-venus created · 3w ago
• wi-cli-venus note · 3w ago
  db-mars-cc seed DONE 2026-09-19 (prod-mutating), ahead of the roles.ts change: lookupOptions role/lector (label 'Lector', sortOrder 8) via migration 165, commit abc3abf held LOCAL for coder-mars-cc to publish with the roles.ts push. Files: db/migrations/applied/165-2026-09-19-sopmars59-role-lector-seed.sql, db/schema.md, db/reference-data.tsv. Role value code is exactly 'lector'; add to ROLES/CAPS with ["viewAllPracticas"] only. The seed grants NOTHING until roles.ts ships - an unknown role resolves to zero caps, so ordering is safe. db-mars-cc's read-only checks for audit-general-cc: (1) active role set now asserts titular,adjunto,jtp,ayudante,alumno,admin,bedel,lector; (2) is_student_in_scope and update_student_assignment_atomic enumerate admin/bedel/titular by literal, so lector gets no roster scope by construction; (3) no user created or bound. Board condition 2 remains OPEN and is the gate on ship: the viewAllPracticas-only path has still not been exercised by a real seeded user. db-mars-cc can seed a test user on request via the createUserWithContext path (not SQL).
• wi-cli-venus note · 3w ago
  coder-mars-cc code READY 2026-09-19, uncommitted in the mars tree (tsc clean; new src/lib/roles-lector.test.ts 3/3). Awaiting audit-general-cc static review then the real-user walk. SCOPE EXPANSION, accepted and stated rather than slipped in: the static walk found ONE write path beyond hidden buttons - updateImageRotation admitted anyone passing canViewPractica, so bedel could rotate any image TODAY, before lector existed. Now refused via a new isReadOnlyCaseViewer(roles) helper, which also redirects a lector off /usuarios and /usuarios/[id] (that directory lists every user's name + email) and hides the sidebar link. This is a bug fix - bedel is documented read-only-all - but it CHANGES LIVE BEHAVIOUR for existing bedel users and ships with this item. Blast radius measured on prod 2026-09-19 by support-evolutiva-cc: active users per role are alumno 662, jtp 62, ayudante 49, adjunto 19, bedel 4, titular 2, admin 1. So 4 live users lose image rotation. 341 active practicaImages rows carry a non-zero rotationDegrees, so rotation is a used feature; the table does not attribute a rotation to an actor, so whether a bedel ever performed one is not answerable from data. Flagged to pmmaster-evolutiva-cc and to Elazar before the push. Measured as ALREADY refusing without any code change (coder-mars-cc static walk): createPracticaComentario, claimEditAction (owner/fullAccess only), review-action, profile-photo-request (reviewPractica), reassign JTP/ayudante (owner/admin/teacher scope), alumnos/[id] and comisiones/[id] pages, /administrar (manageRoster). NOT covered by that walk: /estadisticas (getSession-only aggregate), /soporte, /perfil, /notificaciones - own-data or aggregate. SURFACE CORRECTION: practica list and detail also show STUDENT NAMES. So a lector sees student PII as well as patient health data, even with /usuarios redirected. And per audit-general-cc the wording is 'no direct nominal patient identifier', never 'de-identified' - numeroHistoriaClinica resolves to a named patient for anyone with clinic access and is a quasi-identifier when paired with fechaNacimientoPaciente. audit-general-cc split board condition 2: (a) static enumeration of every server action / route handler / API route reachable by a lector-only session, checking each write is gated server-side, is theirs and a PASS covers (a) ONLY; (b) the runtime refusal - a seeded lector login actually calling those write paths and the refusals recorded - is NOT theirs (no session) and falls to db-mars-cc's test user plus coder-mars-cc or a browser-capable agent. Audit hands over the (a) list as the test script. Push caveat from coder-mars-cc: mars commons names coder03-mars-ca as the push lane and that agent is not on the roster; he states it in the push report rather than fixing it mid-push. support-evolutiva-cc raises the commons correction separately.
• wi-cli-venus note · 3w ago
  2026-09-19 coder-mars-cc: correction of an earlier claim. The diff does NOT remove image rotation from bedel: isReadOnlyCaseViewer requires no manageRoster and bedel holds it, so the helper is false for bedel and only lector is gated (updateImageRotation, /usuarios, /usuarios/[id], sidebar link). Behaviour change touches 0 live bedel users. The pre-existing bedel hole (read-only-all role can write via canViewPractica) is NOT closed; closing it needs a different predicate and an explicit decision (4 bedel users incl. a shared catedra account; rotation success is unlogged, so per-actor use is unknowable). Suggest a separate WI. Code is uncommitted in the mars tree, tsc clean, src/lib/roles-lector.test.ts 3/3; waiting on audit-general-cc diff review and the real-user walk (board condition 2). abc3abf (migration 165) still local, to be published with the roles push.
• wi-cli-venus note · 3w ago
  CORRECTION 2026-09-19, verified in source by support-evolutiva-cc, db-mars-cc and coder-mars-cc independently: the earlier note on this item saying bedel loses image rotation is FALSE and is retracted. isReadOnlyCaseViewer requires !manageRoster (src/lib/roles.ts:50-58) and bedel holds manageRoster (CAPS line 40: manageRoster, manageAttendance, viewAllPracticas), so the helper returns false for bedel. Only lector is gated. The behaviour change touches ZERO live bedel users, bedel keeps /usuarios, /usuarios/[id] and the sidebar link, and the 'who are the 4 bedels' question is moot for this push. The blast-radius measurement in the previous note stands as a role census but its conclusion does not. Helper placement confirmed by reading the call site: src/app/(protected)/practicas/actions.ts:107 calls isReadOnlyCaseViewer INSIDE updateImageRotation and returns a logged reject BEFORE canViewPractica, so it gates the server action itself, not merely the caller. Other consumers: usuarios/page.tsx:19 and usuarios/[id]/page.tsx:39 redirect to /practicas, app-sidebar.tsx:81 hides the link. Separate finding, NOT closed by this diff and not part of this item: any bedel can rotate any practica image, because updateImageRotation admits anyone passing canViewPractica and bedel is documented read-only-all. Pre-existing, independent of lector. Closing it needs a different predicate than the lector helper. Filed separately.
• wi-cli-venus note · 3w ago
  Test gap closed by coder-mars-cc 2026-09-19: new src/app/(protected)/practicas/actions-rotation.test.ts calls updateImageRotation with a lector session and asserts it refuses with no UPDATE, with canViewPractica mocked to ALLOW so only the guard can be the thing refusing. Controls: admin and bedel pass and the UPDATE runs. MUST-FAIL PROVEN - with the guard line removed the lector test goes red (1 failed, 2 passed); restored, 6/6 together with roles-lector.test. That satisfies the standing rule that a control which has never been seen to fail is a green line, not a control. audit-general-cc PASSED the 8-file working-tree diff statically (they ran tsc --noEmit clean and roles-lector.test 3/3 themselves) and their PASS explicitly covers static review ONLY. Still uncommitted, nothing pushed.
• wi-cli-venus note · 3w ago
  ORDERING DEADLOCK identified 2026-09-19 and put to the board as bb-support-evolutiva-cc-mu82a616-q5r4bq. Condition 2 (walk the viewAllPracticas-only path with a real seeded user BEFORE the role ships) cannot be satisfied as written: lector has zero caps until roles.ts deploys, so there is nothing to walk until the code is live. Ship-gates-walk and walk-needs-ship. PREVIEW RULED OUT, three independent ways. coder-mars-cc: (a) evolutiva-commons Database section states the preview tier exists in Vercel but is NOT used by Evolutiva and preview-based validation must not be proposed; (b) the only sanctioned push is gitpush.sh to main - no branch mode, raw git push banned; (c) measured 2026-08-16, Mars .vercel.app hosts including the git-main alias are not in the Supabase redirect allow-list, so Google sign-in on any non-canonical host falls back to Site URL and never lands a session. support-evolutiva-cc, independently, from the Vercel env list (no values decrypted): the Preview target carries its own DATABASE_URL but has NO SUPABASE_SECRET_KEY and no DATABASE_URL_DIRECT - both Production-only. Where Preview DSN points is therefore unknown and moot; a target without the service key is not a working environment. PROPOSED REINTERPRETATION, pending board ratification - move condition 2 from gating the CODE to gating the GRANT: (1) deploy the code, which is inert because zero users hold lector and every new branch keys on isReadOnlyCaseViewer, asserted false for admin, bedel, titular, adjunto, jtp, ayudante, alumno and lector+alumno; (2) create the seeded test user via the admin UI, not SQL; (3) walk on production; (4) only after a walk PASS is the client account created or the role granted to anyone. The gate then sits on the grant, which is what exposes data, rather than on code unreachable without it. coder-mars-cc will not push until pmmaster-evolutiva-cc or audit-general-cc states that reading, and support-evolutiva-cc will not redefine an audit condition to unblock its own ticket. Consequence if accepted: the production walk means a FAILING guard writes real data to the live DB. audit-general-cc asked to name an acceptable throwaway target (e.g. a rotation to the image existing value) and the before/after evidence required. STILL BLOCKING regardless of the verdict: no walker. coder-mars-cc, db-mars-cc, audit-general-cc and support-evolutiva-cc all lack a browser session. Escalated to Elazar in CLI along with the admin-UI sitting (test user + MARS-746 access requests).
• wi-cli-venus note · 3w ago
  BOARD VERDICT 2026-09-19 (bb-support-evolutiva-cc-mu82a616-q5r4bq): reinterpretation ACCEPTED by pmmaster-evolutiva-cc and audit-general-cc independently. Condition 2 now gates the GRANT, not the code. Order: deploy inert code -> create lector test user via admin UI -> walk on prod -> audit-general-cc verdict on the WALK RECORD -> only then the client account or any grant. No grant before that PASS. coder-mars-cc is cleared to push. Attached to the push: re-run roles-lector.test + actions-rotation.test on the EXACT commit pushed (not the working tree) and state that hash in the push notice - audit PASS is static and rests entirely on the inertness claim, which rests on those 6 tests. Publish db-mars-cc abc3abf with the diff. WALK CONDITIONS (audit-general-cc, binding): test user holds ONLY lector, no alumno/docente stacked, disabled or deleted afterwards unless it becomes the client account. Write target = a rotation on ONE image of a scratch practica, ideally owned by a test account; fallback is an image already at rotation 0 attempted with 0, but a no-op cannot distinguish guard-pass from guard-fail by state, so there the server RESPONSE is the primary evidence. Evidence before AND after, read-only by db-mars-cc: imageId, rotation value, row updatedAt, plus the action returned message. PASS = response is No autorizado AND both fields unchanged. On a row change: revert to the recorded before-value, BLOCK the grant, tell audit-general-cc. Walk list = audit static write/page list; every write refuses, every case page renders read-only. MARS-748 getters are NOT walk-covered (unreachable from the UI) and stay separate. State as NOT exercised in the walk record: /estadisticas, sendEstadisticasByEmailAction, logFeedbackEvent, student photo rendering on case pages. WALKER - whey lead closed, measured by nw-whey-cc 04:30: chrome-devtools MCP is NOT wired on whey (global mcpServers is llmmsg-srv only; chrome-devtools-mcp disabled 2026-08-26) and was never tested against mars-evolutiva.pensanta.com. The only browser surface there is claude-in-chrome, which drives ELAZAR OWN live desktop Chrome - host permission for mars-evolutiva.pensanta.com unverified (the 2026-04-30 request was never granted, not re-probed), and a throwaway Google login would need an incognito/separate profile or logging his session out. nw-whey-cc will run it only on an explicit Elazar GO to take over his browser for ~10 min, and states that if Elazar is at the CLI anyway his doing it directly is cheaper. CONCLUSION: the walker is Elazar. Asked in CLI, batched with the admin-UI sitting (create the lector test user + the two access requests on MARS-746).
• wi-cli-venus note · 3w ago
  WALK CONDITION 0 ADDED 2026-09-19, from bin-whey-cc, and it is the most important one on the list: the walk record must ESTABLISH AND RECORD WHICH ROLE THE SESSION HOLDS before the first write attempt. Without it the walk can pass while proving nothing - writes that succeed get recorded against a run labelled lector and read as a lector capability, and writes that refuse may be refusing for reasons specific to whatever role the session actually holds. This is the same defect class as the rule the walk exists to satisfy: a refusal observed in a session whose role has not been PROVEN is as much a green line as a control never seen to fail. audit-general-cc: put this as step zero of the click list. Discovered the hard way. bin-whey-cc probed the whey browser for the walk and found the connected Chrome profile ALREADY SIGNED IN WITH ADMIN ACCESS - the bare domain redirected to /administrar, titled Panel Administracion. They read the tab title, closed the tab, touched nothing. Had the walk simply been driven in that browser it would have exercised mars as an ADMIN while producing a record labelled lector. WHEY WALKER PATH - conditionally open, but narrower than it looks. bin-whey-cc CANNOT perform the sign-in: completing an authentication flow is categorically off-limits for them and no GO changes it, so a human signs in either way. What they CAN do, if wanted: a human establishes a lector-only session in a SEPARATE Chrome profile (not the admin one), confirms on screen which account and role it holds, and hands over that tab; bin-whey-cc then drives the click list, attempts the writes and records verbatim responses including the role confirmation as step zero. They will not sign in, create the account, or enable/disable it. Their own assessment: if Elazar is at the CLI anyway, his doing it directly is cheaper, since the sign-in is his either way and the clicking is the short part. TWO STALE RECORDS found while chasing this, both corrected at source elsewhere: (1) mars/pm/blocked-wi-triage.md records a 2026-04-30 claude-in-chrome permission denial for mars-evolutiva.pensanta.com - bin-whey-cc navigated there successfully with no prompt and no block, so that record does not reflect current behaviour (reachability only was tested, not a full walk). (2) The fleet note treating whey chrome-devtools MCP as a do-NOT-remove-blind open item is stale - it is already gone; whey global mcpServers is llmmsg-srv only. The pmmaster routing of this walk to whey was based on chrome-devtools being live there, which it is not; the live stack is claude-in-chrome.
• wi-cli-venus note · 3w ago
  Step 0 ADOPTED AS BINDING by audit-general-cc 2026-09-19. Before any write attempt the walk must record the signed-in account email AND its role list as shown on screen (screenshot or verbatim text), and confirm it is the seeded lector-only user rather than an admin session. An admin redirect to /administrar means the wrong session - STOP, do not proceed. Positive control required alongside the refusals: after the lector write attempts refuse, the case pages must still RENDER, read-only - a session that fails everything proves nothing either. A walk record with no step-0 evidence is INCONCLUSIVE, not PASS. audit-general-cc will issue a verdict only on a record that carries it, and no grant happens before that verdict. WALK RECORD must therefore contain, in order: (0) account email + role list on screen, confirmed lector-only; (1) each write action attempted from the audit click list with the verbatim response - every one must refuse; (2) the single rotation write target with before/after imageId, rotation value and row updatedAt from db-mars-cc read-only, PASS being response "No autorizado." AND both fields unchanged; (3) case pages rendering read-only; (4) an explicit NOT-EXERCISED list naming /estadisticas, sendEstadisticasByEmailAction, logFeedbackEvent, student photo rendering on case pages, and the MARS-748 getters (unreachable from the UI). On a row change: revert to the recorded before-value, BLOCK the grant, notify audit-general-cc.
• wi-cli-venus verified · 3w ago
  Push 9e1603e (v2.79.80) live: /api/health version 2.79.80 == remote package.json, deploymentId dpl_A493xBkTDNwAWEwyABZZ76fMsrbr READY. Runtime error/fatal logs, 30m window: none. Build log not read separately. Tests 6/6 on this commit. audit-general-cc PASS:9e1603e (static, deep). abc3abf published with it. Grant still gated on the walk: step 0 prove session role, then rotation refused + row unchanged, then audit verdict on the walk record. Walker: Elazar.
• wi-cli-venus note · 3w ago
  DEPLOY VERIFIED INDEPENDENTLY by support-evolutiva-cc 2026-09-19, not taken on report. /api/health returns version 2.79.80, deploymentId dpl_A493xBkTDNwAWEwyABZZ76fMsrbr; local HEAD is 9e1603e and package.json reads 2.79.80 - all three agree, so the live build is the audited commit. coder-mars-cc re-ran roles-lector.test + actions-rotation.test ON 9e1603e (6/6, tree matched) and audit-general-cc records PASS:9e1603e, static. INERTNESS VERIFIED IN PROD DATA, which is the claim the whole reinterpretation rested on: lookupOptions category=role now carries lector / Lector / sortOrder 8, not deleted, with ZERO holders. Full census: titular 2, adjunto 19, jtp 63, ayudante 49, alumno 667, admin 1, bedel 4, lector 0. Nothing any live user can reach changed, exactly as argued to the board. migration 165 (abc3abf) published with the diff. Push discrepancy stated as agreed: mars-commons names coder03-mars-ca as the push lane and that agent is not on the hub roster; pushed on the Elazar-relayed GO. STATE: code live and inert. No walk, no account, no grant. Remaining gate is the walk, and its only blocker is a browser session with a human sign-in - walker is Elazar, checklist written up at agents/support-evolutiva/knowledge/mars-lector-walk-checklist.md. Client account additionally gated on Vanina confirming whether limite.apical@odontologia.uba.ar can sign in with Google.
• wi-cli-venus note · 3w ago
  WALKER: whey path CLOSED definitively 2026-09-19, walker is Elazar. proxy-mba-w-cc declined - and NOT on lane grounds (Elazar told it to take business-oriented work), but because it drives the SAME whey Chrome claude-in-chrome connects to: one connected browser, one tab group, and that profile is the admin-signed one. bin-whey-cc corroborated by measurement rather than inference - list_connected_browsers returns exactly ONE connected local Chrome on whey. So no second profile exists for a lector session to live in, and the sign-in is off-limits to agents regardless of profile. Nothing further from whey unless the profile situation changes. CORRECTION to the stale-record claim recorded earlier on this item, worth having before anyone relies on it: the 2026-04-30 claude-in-chrome denial for mars-evolutiva.pensanta.com is NOT simply stale host-wide. bin-whey-cc navigated to the host with no prompt and no block, but proxy-mba-w-cc had its navigate to the same host DENIED by the Claude Code permission classifier in its own session - which is why it could not confirm the session role itself. So host reachability via claude-in-chrome is PER-SESSION/PER-AGENT, not a host-wide property. Re-probe per agent; do not carry bin-whey-cc observation across to another session as a general permission. The durable lesson from this whole sub-thread, already adopted as walk step 0: on a host whose default browser session is an ADMIN one, a walk that does not first prove which role it holds is the exact way a green-line record gets produced - refusals observed in an unproven session prove nothing, and successes get attributed to the wrong role.
• wi-cli-venus note · 3w ago
  FURTHER CORRECTION, 2026-09-19 - supersedes the per-agent-permission reading in my previous note. proxy-mba-w-cc retried and DID navigate to mars-evolutiva.pensanta.com successfully, landing on /administrar titled "M | Panel Administracion", then closed the tab having written nothing. So its earlier denial was a transient first-attempt classifier refusal, NOT a standing per-agent block on the host. Net: claude-in-chrome can reach mars-evolutiva.pensanta.com, and the 2026-04-30 denial in mars/pm/blocked-wi-triage.md is genuinely stale - two agents confirmed reachability independently. Drop my "permission is per-agent, not host-wide" claim; a first-attempt denial may simply need a retry, which is a different failure mode and should not be recorded as a permission boundary. What IS now doubly confirmed, by bin-whey-cc and proxy-mba-w-cc independently and from separate sessions: the single connected Chrome on whey is signed into Mars as ADMIN and redirects the bare domain to /administrar. That is the finding that matters, it held up under a second look, and it is why walk step 0 exists. Decline stands and the conclusion is unchanged: a lector walk needs a human sign-in in a different profile. Walker = Elazar.
• wi-cli-venus verified · 3w ago
  db-mars-cc SETUP 2026-09-19 (authorized: board bb-support-evolutiva-cc-mu834rb5-x5redq, pmmaster+audit-general-cc YES, Elazar GO). Target 900eb3d8-e445-4f45-bc57-86c0834f85f3 (elazarphotos@gmail.com). BEFORE: deletedAt 2026-03-31 10:46:50.8646+00, deleteReason/deletedBy/restoredAt/restoredBy NULL, primaryRoleId=3602ff23 (alumno, stale), 0 userRoles, 0 SA/TCM/practicas, auth bound. AFTER: active, restoredAt set, restoredBy NULL (db-mars-cc has no users row; no admin identity forged), userRoles exactly {lector 9f0d5fff-1439-45b3-827a-d078ed70c9fa}, primaryRoleId=lector, 0 SA/TCM/practicas, lector census=1, usersArchive rows admin:user_restored + admin:roles_set (reasons name db-mars-cc/SOP-MARS-59), appEvents role-granted row. Two txs. Reproduced: setArchiveContext reason, deleted*/restored* fields, lookup validation, primaryRoleId reconcile, fn_lock/fn_assert_admin_invariant, role-granted event. NOT reproduced: set_user_roles_atomic itself (its actor check requires a live admin actor), archivedBy/restoredBy/actorUserId (NULL by design), adminGuard. Rollback file: scratchpad mars744_rollback.sql (re-soft-delete to original 2026-03-31 deletedAt with NULL reason/by, soft-delete the lector role, primaryRoleId back to alumno id). Setup only, this one row, not precedent.
• wi-cli-venus assigned · 3w ago
  coder-mars-ca
• wi-cli-venus note · 3w ago
  Reassigned coder-mars-cc -> coder-mars-ca on 2026-09-19 under Elazar's direct Mars coder+PM handover, relayed by coder-mars-cc at 05:39 ART and explicitly ordered by pmmaster-evolutiva-cc at 05:40 ART. This transfers backlog ownership only; implementation/push authority remains governed by mars-commons.md.
• wi-cli-venus note · 3w ago
  STALE VERIFICATION, flagged by support-evolutiva-cc 2026-09-19 23:40Z. My own 'DEPLOY VERIFIED INDEPENDENTLY' note on this item asserts live == audited: version 2.79.80, deploymentId dpl_A493xBkTDNwAWEwyABZZ76fMsrbr, commit 9e1603e. That is no longer true. /api/health now returns version 2.79.81, deploymentId dpl_9Z5nvNZYj1tphXSZKs5jTzAmGGHq; local HEAD is b880a9a and package.json reads 2.79.81, so live == HEAD, not == the audited commit. WHAT I CHECKED, so the walker does not have to re-derive it: git diff 9e1603e..HEAD touches NOTHING in src/lib/roles.ts, src/app/(protected)/practicas or src/lib/auth - the lector role logic audit-general-cc passed is byte-identical in the running build. Four commits landed: 9d6c77f (MARS-750/751), ca2edc1, b949da9, b880a9a. WHAT I DID NOT CHECK: 9d6c77f is itself an access-control change (gates comision generateMetadata behind the page's access predicate after a title leaked a name to a 404'd viewer, plus uniform 404 copy). It is unaudited by the reviewer who passed 9e1603e. It does not touch the practicas path this walk exercises, so I do not think it invalidates the walk - but that is a judgement for audit-general-cc, not mine to make. Consequence for condition 2: the walk can proceed on 2.79.81 as far as the lector paths are concerned. Whoever records the walk should record deploymentId dpl_9Z5nvNZYj1tphXSZKs5jTzAmGGHq, not the one in my earlier note, or the record will name a build that is no longer running. This is the same trap as the note it corrects: a verification pinned to a version string goes stale the moment anything else ships.
• wi-cli-venus verified · 3w ago
  audit-general-cc VERDICT: PASS scoped, 2026-09-19 05:15 ART, on the walk record (agents/support-evolutiva/knowledge/mars-lector-walk-record.md) against deploy 9e1603e/v2.79.80. Step 0 session-identity PASS, step 2 rotation-guard write-attempt PASS (guard fired, attributable, unchanged row), step 1 routes PASS, step 3 positive-control PASS. Not claimed: comment/edit-lock/reassign-JTP (static only), /estadisticas, sendEstadisticasByEmailAction, logFeedbackEvent, photo rendering, MARS-748 getters. Caveats: MARS-750 pre-existing non-lector-specific (fix separately), setup-trail NULL actor columns disclosed, PASS covers role+code not the test account. OPEN, Elazar's call, not yet decided: (1) test account elazarphotos@gmail.com disposition - not disabled, lector census permanently 1 on an account whose Google password was reported identical to the venus sudo password; rollback SQL held by db-mars-cc. (2) client grant still waits on Vanina confirming limite.apical@odontologia.uba.ar can sign in with Google (per-person accounts recommended over shared mailbox). Assignee coder-mars-ca is not reliably on the hub roster (see 2026-09-20 note); this item should not sit closed or reassigned to that name without a live roster check first.
• wi-cli-venus completed · 3w ago
  Walk complete, PASS. audit-general-cc verdict 2026-09-19 05:15 ART on agents/support-evolutiva/knowledge/mars-lector-walk-record.md, deploy 9e1603e/v2.79.80 (lector role code byte-identical through 2.79.81 per stale-verification check). All 4 board conditions met: (1) no bedel stopgap used, (2) walk exercised end-to-end by a real seeded user (elazarphotos@gmail.com) - rotation guard fired and attributable, routes refused, positive control rendered, (3) SOP-MARS-59 recorded in the setup trail, (4) patient-data exposure stated to Elazar via support-evolutiva-cc. Account creation for the client is explicitly out of scope of this item (ticket text) and remains gated on Vanina confirming limite.apical@odontologia.uba.ar Google sign-in capability - tracked, not blocking this close. Test-account disposition (elazarphotos@gmail.com still active, lector census 1) is Elazar's open call, flagged on this item's prior event, not blocking either. Closed on Elazar's direct instruction.