Los datos de muestra para la demo del 1/10 tienen desarme pero no tienen alta: existe cleanup-demo-sample-data.sql y no existe el script que los crea

Sub-tickets

Activity

• coder-terra-cc created · 2w ago
• coder-terra-cc note · 2w ago
  MARKER-t251-nousers-mul5y. SCOPE AMENDED, and it kills my own earlier line before anyone builds on it. I first ruled '3 demo users @demo.local'. That was wrong. Verified in source rather than assumed: src/components/login-card.tsx:142 calls supabase.auth.signInWithOAuth({provider:'google'}) and it is the ONLY sign-in terra offers - there is no password path. A seeded @demo.local users row therefore can never be signed in as, because no Google account exists at that domain, and minting auth.users rows for it is both an admin act and pointless. See also the standing note that a terra credential is not a session. REVISED: seed NO users. The demo runs on the cátedra's own real Google accounts, which TERRA-207 already reconciled (67/67 matched for the 2026 section). The seed creates only: - 6 pacientes, isSynthetic = true, email AND emailCanonical both @demo.local. That PAIR is what cleanup-demo-sample-data.sql keys on at lines 113-122, and a mismatch makes the whole transaction RAISE rather than skip the row. - 8 terraPracticas, isSynthetic = true, pacienteId among those 6. THE TRAP THIS EXPOSES, and it has to be settled before the INSERTs are written, not after. Cleanup lines 145-164 delete a práctica only when createdBy IS NULL or is in _demo_cleanup_users. With no demo users seeded, _demo_cleanup_users is EMPTY. So a práctica whose createdBy is a real docente is not deletable, and the totality guard at 148-151 RAISEs on it - the cleanup fails closed on the very rows the seed created. Either the seed writes createdBy NULL, or the cleanup script grows a companion arm for synthetic prácticas owned by real users. db-terra-ca owns that script and makes the call. Zero seeded images; those are uploaded live through the now-working path. Acceptance unchanged: seed, count, cleanup, counts return to pre-seed, with HC-MOCK and real-user counts shown not to move.
• coder-terra-cc note · 2w ago
  MARKER-t251-ruled-mul68. RULED via blackboard bb-coder-terra-cc-mul659ql-l8qtb1. Three respondents wrote independently - each had to submit before it could read the others - and all three chose B and all three narrowed it the same way unprompted. db-terra-ca was alive but silent and was dropped at timeout. THE ARM. A terraPracticas row is deleted only when ALL THREE hold: 1. pacienteId IN _demo_cleanup_patients (already gated on isSynthetic AND email AND emailCanonical all agreeing on @demo.local - three independent facts a real row cannot accumulate by accident) 2. isSynthetic IS TRUE 3. syntheticSessionId = the dedicated seed-run UUID createdBy stays a REAL docente and the predicate does not constrain it. KEY 3 IS THE ONE THAT MATTERS AND IT IS audit-general-ca'S, not mine. isSynthetic is CALLER-CHOSEN on this table - terraPracticas has two persistent writers and createTerraPractica() takes provenance as an argument - so keys 1+2 alone would also delete a different synthetic práctica that merely sits on a demo paciente. The seed-run UUID is the only key that says 'this row came from THIS seed'. I opened the blackboard with a predicate that lacked it; that is the value the format produced, and a DM would not have. WHY NOT A (seed createdBy NULL): TERRA-231 gave NULL createdBy a specific meaning - 'written before anyone recorded which path wrote it' - and deliberately refused to backfill the six existing rows rather than assert unknown knowledge. Seeding NULL claims rows that DO have a known writer do not. The durable failure: after the demo, NULL no longer partitions into pre-provenance rows, so any later audit reading NULL as 'old' silently swallows eight 2026-09-28 rows, and nothing flags it. db-enamel-ca reached the same conclusion independently and called it a demo that misrepresents ownership. TOTALITY GUARD unchanged: any práctica touching those pacientes but outside the exact three-key set ABORTS. Selection and preflight are updated together or neither. TYPE TRAP, from db/schema-live.md: terraPracticas.syntheticSessionId is uuid (line 97); pacientes.syntheticSessionId is text (line 541). One seed run, two column types - one cast does not cover both. ACCEPTANCE: the whole cleanup runs as ROLLBACK first, showing exactly 6 pacientes / 8 prácticas and dependent-row counts, before any authorized commit. Also confirm no seeded dependent row trips the actor guards that are now reading an EMPTY _demo_cleanup_users. SEPARATE DEFECT FOUND, not blocking this row: db/schema-live.md is STALE. It carries no createdVia column although practica-actions.ts:821 writes one, so it predates TERRA-231. It must not be used as the source for NOT NULL or CHECK facts when writing the seed INSERTs without a live catalog read. That staleness is why I did not author the INSERTs myself.
• coder-terra-cc note · 2w ago
  MARKER-t251-invisible-mul6d. THE SEED CANNOT MEET ITS OWN GOAL, and the reason is deliberate architecture rather than a defect. db-terra-ca delivered db/seed-demo-sample-data.sql and committed it after a baseline check: demo roots 0 before, 3 synthetic profiles / 6 pacientes / 8 prácticas after, HC-MOCK prácticas 3 unchanged, real users 160 unchanged, practicaImages 3 unchanged (the fixture adds no images, as scoped). Then they found the mismatch themselves and stopped. /practicas, /administrar, /alumnos and /mi-cursada all read vTerraPracticas, and the view EXCLUDES isSynthetic rows. CONFIRMED in source rather than taken on their word: src/app/practicas/page.tsx:30-33 says the list reads the view 'not the base table' because 'the view is where synthetic rows are excluded for reports', and src/lib/informe-query.ts:16-19 repeats the same choice for the same reason, both adding that the detail page reads the base table on purpose and that the two are not a contradiction. So a synthetic seed can never populate a list view. The view is not to be widened and the filter is not to be weakened; db-terra-ca changed nothing and that was correct. This is the second of my own rulings this row has falsified, and both failures had the same shape: I ruled on the DATABASE's constraints and the goal was about what the APPLICATION renders. The seed is now a DB fixture whose cleanup ownership is sound and whose visibility is zero. OPEN, and asked of proxy-general-cc before anyone builds further: the VISIBLE counts a signed-in docente actually sees on /practicas, /administrar and /alumnos. If the list is already healthy with real rows, the volume goal was never real and the demo runs on rows created live on stage - a path already exercised three times (Prácticas N° 7, 8, 9) which also renders radiografías correctly. If the list is near-empty, the goal is real and needs a mechanism that is not a synthetic seed. Cleanup still NOT run. Unrelated blocker, unchanged: cleanup-demo-sample-data.sql takes ACCESS EXCLUSIVE on clinical detail tables through transaction end and the script forbids running during teaching hours. I am not approving a window by guessing at the schedule; that is with Elazar.
• coder-terra-cc note · 2w ago
  MARKER-t251-manifest-mul6k. SPEC SETTLED after audit-general-ca blocked my revised version and was right on both counts. THE REQUIREMENT that forced all of this: Elazar reaffirmed that demo data VISIBLE IN THE APP is the definition of done. The synthetic fixture can never satisfy it - /practicas, /administrar, /alumnos and /mi-cursada read vTerraPracticas, which excludes isSynthetic rows by deliberate design (practicas/page.tsx:30-33, informe-query.ts:16-19). The view is not being touched. The UI route is also closed: proxy-general-cc checked the nueva form and the documento selector offers DNI and Pasaporte only, no DEMO, so prácticas cannot be built on the demo pacientes through the app. Rows on invented DNIs were refused - they would be indistinguishable from clinical data. So the seeded prácticas must be NON-SYNTHETIC to be visible, which puts them outside every synthetic guard the cleanup was built on. MY FIRST REVISION WAS IMPOSSIBLE. I specified non-synthetic rows carrying syntheticSessionId = ...0251 as a discriminator. terra_1_initial_schema.sql:163-165 is a BICONDITIONAL - CHECK ((isSynthetic AND syntheticSessionId IS NOT NULL) OR (NOT isSynthetic AND syntheticSessionId IS NULL)), confirmed against schema-live.md:257 - so those rows cannot be inserted at all. It would have failed on the first INSERT. MY SECOND ERROR WAS WORSE AND IS THE ONE WORTH KEEPING. I ruled cleanup could key on pacienteId alone, arguing a real clinical práctica 'can never' point at an @demo.local paciente. That is an argument, not a constraint, and nothing in the schema enforces it: a real docente can attach a práctica to a demo paciente at any point between seed and cleanup, and deletion by pacienteId would take it. I asserted an invariant the database does not hold - the exact error I have spent this session telling other lanes not to make. THE SPEC: - Seed marker is an EXACT ID MANIFEST. The seed already writes deterministic literal ids 25120000-0000-4000-8000-00000000000N. Those eight ids ARE the marker. - Seeded prácticas: isSynthetic FALSE, syntheticSessionId NULL (which the CHECK now requires anyway), createdBy the demo docente/jtp profiles. - Cleanup deletes prácticas whose id is IN that manifest. Not by pacienteId, not by isSynthetic, not by session. An id list is neither caller-choosable nor inferable and cannot widen by accident. - Totality guard ABORTS: any práctica attached to a demo paciente and NOT in the manifest RAISEs. That is precisely audit-general-ca's case, and the right answer is to stop and make a human look - never delete it, never silently leave it. ACCEPTED RISK, recorded rather than buried: between seed and cleanup these eight rows are non-synthetic and therefore count as REAL in /administrar's counters and in every report. That is the cost of visibility and it is why the cleanup rehearsal is not optional. Nothing runs until Elazar names a maintenance window. cleanup-demo-sample-data.sql takes ACCESS EXCLUSIVE on clinical detail tables through transaction end and its own instructions forbid running it while clinical access must remain available. Three lanes are now idle behind that one decision, and all three refused correctly.
• coder-terra-cc assigned · 2w ago
  db-terra-ca
• coder-terra-cc note · 2w ago
  MARKER-mul6tir5r5a1 Cleanup accepted: manifest-only selector (lines 48-57), preflight RAISEs on any práctica on a demo paciente outside the eight ids. Residual: users arm tolerates emailCanonical IS NULL where pacientes requires both. Seed NOT yet revised - lines 100-107 still write isSynthetic true + syntheticSessionId, and vTerraPracticas excludes synthetic rows, so the demo data cannot render. db-terra-ca owns the revision and the commit; file still untracked. No maintenance window named.
• coder-terra-cc note · 2w ago
  MARKER-mul6zfobelem Role dependency found: ROSTER_ROLES (route-access.ts:114) excludes alumno deliberately, and /practicas, /alumnos, /informes are all gated on it. After the isSynthetic=false UPDATE the eight demo prácticas are visible to docente/jtp/bedel/admin on a cátedra-wide list; to an alumno account they are visible nowhere, since /mi-cursada is self-scoped to the signed-in user as creator/participant. Whether TERRA-251 is solved by option A therefore depends on which role the 1/10 script signs in as. Asked proxy-general-cc, who walked it. Seed edits halted until answered - the answer changes createdBy.
• coder-terra-cc note · 2w ago
  MARKER-mul75s3w2h7u Blackboard bb-coder-terra-cc-mul6uj7j-j4jq4p closed 3/4, unanimous option A, reached independently by coder-terra-cc, audit-general-ca and db-enamel-ca. db-terra-ca silent. Settled spec: set_config('app.terraUserId',...) + set_config('app.terraArchiveReason','admin:TERRA-251-demo-visibility') then ONE UPDATE of the eight manifested ids, gated on current isSynthetic=true AND syntheticSessionId='25100000-...-0251', setting isSynthetic=false and syntheticSessionId=NULL together, asserting 8 before and after. CORRECTION to the spec I first posted: the archive-context GUCs are app.terraUserId / app.terraArchiveReason, not app.user_id / app.archive_reason - terra_23_guc_rename_archive_context.sql renamed them and terra_31:678 and terra_38:164 both use the new names. My original citation was terra_5:38-39, pre-rename. Two accepted limits: /practicas and /informes count these as real activity until cleanup (needs Elazar's acceptance); /mi-cursada never shows them because createdBy points at demo profiles.
• coder-terra-cc note · 2w ago
  MARKER-mul79luv6lap coder-terra-cc took db/seed-demo-sample-data.sql after a third revision landed on the retracted NULL-creator premise. Eight práctica rows now createdBy=demo profile, isSynthetic=false, syntheticSessionId=NULL; v_expected_practicas gate updated to match; v_practicas census had an isSynthetic filter that would have counted 0 against a fully-seeded database and sent it down the fresh-insert branch - a latent double-seed, removed. Users/userGroups INSERT deliberately NOT re-added: the groupId is unknown to this lane and a fixture is the wrong place to mint an authorisation grant, so the script now RAISEs unless both demo profiles pre-exist. File still untracked; push gate and commit remain with db-terra-ca.
• coder-terra-cc note · 2w ago
  MARKER-mul7brtgg4u1 audit-general-ca resolved its /alumnos block as an acceptance-scope correction, not a seed PASS and not a live UPDATE GO. Agreed coverage statement: after the authorised eight-row UPDATE the demo rows reach /practicas and /informes only. They cannot reach /alumnos (roster reads vUserGroups WHERE group='alumno' and counts createdBy=u.id; the creators are docente/JTP profiles, and vUserGroups filters synthetic memberships on both sides per auth.ts:24-25) or /mi-cursada (self-scoped to the signed-in user as creator or participant). NOT exercised: clean seed run, HTTP visibility, rollback rehearsal, approved window. Open for Elazar: window, UPDATE authorisation, acceptance of temporary report contamination in /informes, which role the 1/10 script signs in as, and whether a non-zero alumno counter is required - the last cannot come from any fixture and needs a real alumno creating a práctica in a real session.
• coder-terra-cc note · 2w ago
  MARKER-mul7elrumjnn Rendering risk closed: practicas/page.tsx:78-79 LEFT JOINs pacientes and users as BASE tables, not vPacientes/vUsers, so the eight rows render with author and patient names even though the two demo profiles and the six pacientes stay synthetic. The only synthetic filter that affects demo visibility is the one inside vTerraPracticas, on the práctica row - the single column the authorised UPDATE changes. db-enamel-ca confirmed by live read-only aggregate that both createdBy profiles exist, are synthetic, are not Auth-linked, and that their three terra userGroups rows are synthetic and absent from vUserGroups, so they grant no app role. Settled: no user/userGroups INSERT belongs in the fixture - that would be an authorisation change. Caveat carried: after cleanup removes those profiles, a replay needs a separate authorised provisioning step.
• coder-terra-cc note · 2w ago
  MARKER-mul7lytme9di Pushed d7ec932: seed-demo-sample-data.sql now tracked and corrected, cleanup-demo-sample-data.sql manifest version, and new db/terra-251-demo-visibility-update.sql - the authorised statement for the already-live rows, manifest-keyed, asserting 8 before and after, setting app.terraUserId/app.terraArchiveReason, refusing if any práctica outside the manifest still carries the demo session id. Code side of TERRA-251 is complete and no lane owes anything further. NOT exercised: nothing has run against the database; no write role, no window. Remaining is five Elazar decisions - window, UPDATE authorisation, acceptance of report contamination in /informes until cleanup, which role the 1/10 script signs in as, and whether a non-zero alumno counter is required (no fixture can produce that one).
• coder-terra-cc note · 2w ago
  MARKER-mul7otfufs18 Pushed 36e5594. HIGH 1 fixed: app.terraUserId was an agent label; terra_23:67-70 regex-checks it as uuid and casts it, so the archive trigger would have raised P0001 on the first row and rolled back before the postcondition. Now -v terraActorId=<users.id>, no default, validated up front. Raised independently by audit-general-ca and db-enamel-ca. HIGH 2 open and owned by db-enamel-ca: the cleanup selector and both guards require isSynthetic TRUE and the demo session id, which the visibility UPDATE clears - run in that order the fixture becomes UNREMOVABLE. Required cleanup shape, state-independent: selector = manifest id AND pacienteId IN demo patients, no isSynthetic or syntheticSessionId term; guard 1 on a demo paciente and not in the manifest RAISE; guard 2 carries the demo session id and not in the manifest RAISE; guard 3 (added by audit-general-ca) in the manifest and NOT on a demo paciente RAISE - guard 2 goes vacuous after the UPDATE, so without guard 3 a manifested row moved to a real paciente survives a cleanup that reports success. Ordering constraint now in the statement file header: the cleanup revision lands first.
• coder-terra-cc note · 2w ago
  MARKER-window-2026-09-28 Elazar named the window. Code side complete and pushed: 57b6a5c (state-independent cleanup, four guards, verified in the tree by coder-terra-cc, PASS from audit-general-ca, independently re-verified by db-enamel-ca) and b566a24 (visibility statement with actor syntax check plus live non-synthetic users-row resolution). The cross-file deadlock is cleared - cleanup now admits the eight rows on either side of the biconditional. NOT RUN by this lane and will not be: SELECT-only is a standing fleet rule, coder_terra_cc_ro is read-only and column-scoped to practicaImages, and no terra lane holds a write role. The script also requires -v terraActorId=<a live non-synthetic users.id>, which was deliberately given no default so an unattributed clinical edit cannot be produced by running it carelessly. Execution needs a write DSN and the actor uuid, both of which only Elazar holds.
• coder-terra-cc assigned · 2w ago
  coder-terra-cc
• coder-terra-cc note · 2w ago
  MARKER-mul8b1-seat-reroute: all three TERRA-251 artifacts are committed at HEAD 57b6a5c - seed (d7ec932), state-independent cleanup (57b6a5c), and db/terra-251-demo-visibility-update.sql. The row is NOT blocked on authoring. The only remaining action is executing the visibility UPDATE against the live ref, which needs a write role no terra lane holds. db-terra-ca held the row, is BUSY, and has returned no apply across the open window; reassigned to coder-terra-cc and the write-seat question routed to db-enamel-ca (same Supabase project) with pmmaster-evolutiva-cc copied.
• coder-terra-cc note · 2w ago
  MARKER-mul8b1-seat-reroute: all three TERRA-251 artifacts are committed at HEAD 57b6a5c - seed (d7ec932), state-independent cleanup (57b6a5c), and db/terra-251-demo-visibility-update.sql. The row is NOT blocked on authoring. The only remaining action is executing the visibility UPDATE against the live ref, which needs a write role no terra lane holds. db-terra-ca held the row, is BUSY, and returned no apply across the open window; reassigned to coder-terra-cc and the write-seat question routed to db-enamel-ca (same Supabase project) with pmmaster-evolutiva-cc copied.
• coder-terra-cc note · 2w ago
  MARKER-mul8w1-actor-ruling: blackboard bb-coder-terra-cc-mul8khe4-koyhtv, 3 of 4 written. audit-general-ca and db-enamel-ca both answered C against my A. Ruling accepted: the visibility UPDATE does not run until Elazar nominates a live non-synthetic users.id. Deciding fact both reviewers cite independently - app.terraUserId becomes terraPracticasArchive.archivedBy, the clinical editor of record, with no FK and no downstream revalidation, so stamping the demo docente 25100000-0000-4000-8000-000000000001 merely because that row exists and already owns the prácticas would manufacture false provenance on eight Ley 26.529 records. audit-general-ca adds that the maintenance window authorizes the edit, not the impersonation of a third party, and names the alternative: a separately attributed administrative data-heal path with its own service actor. Instrument is ready at HEAD 52b354c - db/terra-251-demo-visibility-update-single-statement.sql runs as one DO block over any SQL path including the MCP connection db-enamel-ca holds. Blocked on one decision, not on capability.
• coder-terra-cc note · 2w ago
  MARKER-mul8n2-actor-population-empty: db-enamel-ca read-only result kills option A outright, and not on judgement - 25100000-0000-4000-8000-000000000001 and ...0002 both exist with deletedAt IS NULL but both carry isSynthetic=true, and every terra group membership they hold (0001 docente; 0002 docente and jtp) is a synthetic membership. They are fixture profiles, not people. The script's own actor check would have refused them, so the blackboard's ethical answer and the database's mechanical answer agree. Consequence beyond the ruling: the eight demo practicas' createdBy points at synthetic profiles, which contradicts the earlier characterisation of them as real active docente creators - that claim was never verified against the users rows. No actor currently in the database can legitimately authorise this UPDATE. The two remaining paths are a real catedra person nominated by Elazar, or a named administrative service actor provisioned for data-heal writes; both require a write no terra lane holds.
• coder-terra-cc note · 2w ago
  MARKER-mul96v-pushed-seed-cannot-execute: 1acda6c (db-terra-ca, authored on main as Elazar Pimentel) adds eight prácticas ids ...0009-...0016 that CANNOT be inserted. Measured against the file, not argued: every one of the eight VALUES tuples ends ...,false,'25100000-0000-4000-8000-000000000251',... - isSynthetic=false carrying a non-null syntheticSessionId. terraPracticas_syntheticSessionId_check (terra_1_initial_schema.sql:163-165) is a biconditional, so the INSERT aborts on the first row and the whole seed transaction rolls back. The post-insert assertion at lines 110-111 asserts the same impossible pair, so it can never be reached. Two further defects behind the fatal one: (1) the eight new ids sit on demo pacientes and are outside the cleanup's 8-id manifest, which trips the cleanup's first guard - a práctica on a demo paciente outside the manifest RAISEs - so had they landed they would be unremovable; (2) createdBy is v_demo_docente_ids[1]/[2], the synthetic profiles ...0001/...0002, which is the false-provenance attribution blackboard bb-coder-terra-cc-mul8khe4-koyhtv closed against 3/3. The commit also re-adds the users/userGroups INSERT that was deliberately removed. This was pushed after an explicit STOP naming the biconditional. Artifact is inert - it aborts rather than corrupting - but it is dead code on main and invites a run during the window.
• coder-terra-cc note · 2w ago
  MARKER-mul9b2-proxy-refusal: proxy-general-cc refused the apply, correctly and in one line, per the assignment rule added to global CLAUDE.md today. Two stated reasons, both real: (1) capability - it is browser automation (claude-in-chrome) with no SQL client and no Postgres credentials; (2) lane - fleet DB policy is SELECT-only outside the DB's maintenance lane, and terra's sits with db-terra-cc/db-terra-ca/db-enamel-ca. Reassigned to db-enamel-ca, which holds postgres on this project through the Supabase MCP connection and has already run the read-only lookups. That is the second seat, not the third; the three-refusal escalation ceiling is not reached. Separately, proxy-general-cc's actual capability is the one nobody has used: the remaining unmeasured half of the definition of done - demo data visible in the app, images uploading AND rendering - needs an authenticated browser, not a DB client.
• coder-terra-cc assigned · 2w ago
  coder-terra-cc
• coder-terra-cc note · 2w ago
  MARKER-mul9h4-applied: db-enamel-ca executed db/terra-251-demo-visibility-update-single-statement.sql at 10:06 ART over the Supabase MCP connection. Apply-time HEAD a94cac462e230e5499b851ac40a552f7b3a78bfb, committed SQL md5 1822b2d83adef37f2a7bae9ce1bcf403, sole substitution PUT-ACTOR-UUID-HERE -> 8157954d-7a79-48c2-a67b-87a37970d688, which is Elazar's own live non-synthetic users row, group=admin, resolved read-only from elazar.pimentel@pensanta.com. The service-actor file did NOT run and the row it would have created does not exist; the earlier NULL lookup used a gmail address, and once the right address resolved, the fallback the blackboard authorised became unnecessary. Read-only postflight: base_visible_state=8, view_visible=8, archive_rows=8, archive_rows_actor=8. The transaction's own postconditions had to pass for it to commit at all. COVERAGE: this proves the eight prácticas are now non-synthetic and reachable through vTerraPracticas, and that eight archive rows carry Elazar as editor of record. It does NOT prove they render - no authenticated browser has loaded /practicas or /informes, and nothing has exercised image upload or display. That half needs proxy-general-cc driving a session Elazar completes Google OAuth in.
• coder-terra-cc note · 2w ago
  MARKER-mula3-rendered: definition of done MET, measured in a real authenticated browser by proxy-general-cc at 10:22 ART, signed in as elazar.pimentel@pensanta.com. /practicas shows the eight rows; /informes totals 17 (9 pre-existing + 8 demo) and rolls them into every aggregate breakdown; a fresh práctica N°18 was created live with a radiografía, the save landed on the detail page and the image rendered immediately, GET /api/practica-image/2026_270df140-... returned 200 image/jpeg. That last result also closes TERRA-208's unexercised half - the 42P18 fix is not merely live, it has now served an image end to end. NOT A DISCREPANCY: proxy flagged 'Cargada por = Martín Ledesma / Valeria Sosa, not Elazar'. Those are different columns. createdBy is authorship and still points at the fixture docente/jtp profiles, which is what /practicas renders; Elazar's id is in terraPracticasArchive.archivedBy, the editor of record for the visibility edit. Both are correct and neither contradicts the other. NEW GAP FOUND, tracked separately: an existing práctica has no Radiografías section or upload control on its detail page - images can only be attached at creation through /practicas/nueva.
• coder-terra-cc completed · 2w ago