# Verification record — `br/pr/iipr/carteira-identidade-correcao` v1.0.0

This file is the **source-review record** for this document version, per the
[`manual-source-review-v1`](../../../../../../practices/manual-source-review-v1.md)
practice. It documents the provenance of the published fields and flow and
states the current verification claim honestly.

## Current claim

- **`status`:** `draft`
- **`verification.method`:** `manual-source-review-v1`
- **`verification.lastVerifiedAt`:** `2026-07-07`

Every field was confirmed either directly on-screen via a live Playwright
render of the real app, or by decompiling that same session's own compiled
Vue single-file-component render functions (real label text, option lists,
input masks, required-field markers — not just internal `$parent.form.<x>`
field names). It remains `draft`, not `verified`, because the data-entry
form's fields beyond the eligibility gate could not be walked with real
submitted data (see "Mock-data test run" below), and a second independent
reviewer's pass has not yet occurred.

## Why this candidate, and the DNS correction

Two prior `GovSchema Standard Research` cycles found and flagged this
candidate:

- **GOV-1616** (2026-07-07) first deep-dived Brazil's National ID gap
  (Carteira de Identidade Nacional, CIN) and found Paraná's RCI system
  (Registro Civil de Identificação) — the only Brazilian National ID
  candidate in this registry's history with a genuinely rich, unauthenticated
  field set, discovered by grepping the compiled `app.js` bundle for
  `$parent.form.<field>` references. It was rated the strongest-ever-found
  candidate but deliberately **not authored that cycle**, since confirming
  each field's real on-screen label/requiredness needed a live-rendered pass
  of the Vue app, not just static JS-bundle field-name inspection.
- **GOV-1624** (2026-07-07, later the same day) re-confirmed this candidate
  as strong and ready-to-author but again deferred it, picking Chile's SII
  Formulario 4415-PN instead for that cycle, explicitly leaving this Paraná
  candidate "for a dedicated future cycle."

**This document is that dedicated cycle.**

Both prior cycles' own notes cite the bare hostname `rci.pr.gov.br`
(without a `www.` prefix). That citation is now stale: as of 2026-07-07,
`rci.pr.gov.br` does not resolve in DNS at all — confirmed three independent
ways:

```
$ getent hosts rci.pr.gov.br          # no output, exit 2 (NXDOMAIN-equivalent)
$ python3 -c "import socket; socket.gethostbyname('rci.pr.gov.br')"
socket.gaierror: [Errno -2] Name or service not known
$ curl 'https://dns.google/resolve?name=rci.pr.gov.br&type=A'
{"Status":3, ...}   # NXDOMAIN
```

The real, live, working host is **`https://www.rci.pr.gov.br`** (with the
`www.` prefix) — confirmed `HTTP 200` on both
`https://www.rci.pr.gov.br/pedido` and
`https://www.rci.pr.gov.br/solicitante/iniciar`. It is embedded via an
`<iframe>` on `https://www.policiacivil.pr.gov.br/Pagina/Correcao-de-Solicitacao`
(also `HTTP 200`, confirmed by fetching the page's raw HTML directly:
`<iframe height="890" src="https://www.rci.pr.gov.br/pedido" width="100%">`),
and linked from IIPR's own service-catalog pages under "Identidade (CIN)" on
`policiacivil.pr.gov.br` (see "Second corroborating source" below). No
login, CAPTCHA, or WAF gate blocks any of these three pages.

## Live-render technique

A Playwright (`playwright-core`, chromium) session was launched headless
against a real Chrome binary (with the `LD_LIBRARY_PATH` workaround this
environment requires for missing system libs), using a realistic desktop
user agent and a 1366×900 viewport. Three screens were walked and
screenshotted:

1. **`https://www.rci.pr.gov.br/solicitante/iniciar`** — "SOLICITAÇÃO
   ON-LINE DA CARTEIRA DE IDENTIDADE NACIONAL – CIN / Exclusivo para
   documentos expedidos no Paraná." A single visible field, `num_doc`
   ("Número do documento" — the applicant's existing Paraná RG-with-check-digit
   or CPF number), gated behind a "Verificar" button that stays `disabled`
   until the input passes a client-side length check. Submitting it POSTs to
   `solicitante/verificarRg`, which server-side-checks the number against
   IIPR's own existing-record database and returns one of several outcomes
   (all present as hidden template strings in the page's own DOM, confirmed
   by reading the raw HTML): an existing-open-protocol prompt, an
   in-person-only rejection (twice — once generic, once for the Lei
   10.048/2000 "grupo preferencial" case), a genuine "cadastro disponível"
   success state (which then reveals `nome`/`data_nascimento` confirmation
   fields), a data-mismatch error, and a rate-limit error.
2. A **"Não sei meu número"** ("I don't know my number") link, confirmed
   live: clicking it reveals **"Clique aqui para agendar"** — an in-person
   scheduling link — confirming that citizens who don't know their existing
   RG/CPF number are routed to an in-person appointment, not any synthetic
   online path.
3. **`https://www.rci.pr.gov.br/pedido`** — "Correção de Solicitação." A
   single visible field, `celular` (mobile phone number, masked
   `(DDD) _____-____`), gated behind a "Validar" button. This is IIPR's
   *separate* re-entry point for a citizen who already submitted a request
   and was sent an SMS by IIPR asking them to fix specific flagged items —
   distinct from, but functionally overlapping with, the `solicitante/iniciar`
   gate (confirmed by decompiling both components: they share the same
   phone/SMS-code verification sub-flow, and once past either gate the
   citizen reaches the same set of correction screens — see "Component
   reconstruction" below).

## Mock-data test run

Per this cycle's brief, a synthetic-but-checksum-valid CPF,
**`529.982.247-25`** (a well-known Brazilian placeholder/test CPF that
passes the standard two-check-digit modulo-11 algorithm — verified by hand:
first check digit from weights 10..2 over `529982247` sums to 295, `295 mod
11 = 9`, `11-9=2` ✓; second check digit from weights 11..2 over
`5299822472` sums to 347, `347 mod 11 = 6`, `11-6=5` ✓), was typed into the
`num_doc` field and submitted live:

- **Result:** `"Atenção: O seu cadastro no Paraná não está disponível para
  a solicitação on-line da CIN. É necessário realizar o agendamento para
  atendimento presencial."` — i.e. correctly rejected, since no real IIPR
  record exists for this synthetic number. Screenshot:
  `after-verificar3.png` in this cycle's working notes.
- The same synthetic approach was also tried against the *separate*
  `celular` (phone) gate on `/pedido`, with a synthetic number
  `(41)99999-8888`: **Result:** `"Pedido não encontrado"` ("Request not
  found") — again a correct rejection, confirming genuine server-side
  validation on both entry points, not a client-side-only check.

This confirms — as this cycle's brief anticipated — that **no synthetic
value can pass either eligibility gate**: the data-entry form's fields
beyond this point genuinely require a real existing Paraná RG/CIN holder's
credentials to reach live. This is a normal, previously-seen sourcing limit
in this registry (e.g. several published schemas combine a live-DOM walk up
to a real-record gate with the same app's own compiled source for what lies
beyond it). No real personal data was ever entered; no submission was
completed; client-side validation was the deepest point reached live.

## Component reconstruction (beyond the gate)

`https://www.rci.pr.gov.br/js/app.js?id=1fff2a22899fb4be9662` (2.2MB,
directly downloadable, `HTTP 200`, no login/CAPTCHA/WAF) is a webpack
bundle of a Vue 3 (Options API) app compiled with `vue-loader`'s
`@vue/compiler-sfc`. Unlike a typical minified bundle, each Single File
Component's `render()` function is compiled to explicit
`createElementVNode(tag, props, children)` calls with **hoisted static
VNodes** (`_hoisted_N` variables) — meaning every literal on-screen label,
help-text string, and `<option>` list survives compilation as a plain
JavaScript string literal, not just the field's internal camelCase name.
This cycle located and extracted each relevant component's own webpack
module (keyed by its unique `?vue&type=template&id=<hash>` module path) and
read its labels, masks, and option lists directly, rather than trusting the
`$parent.form.<field>` names GOV-1616's grep-only pass had surfaced. This
caught one genuine discrepancy with the prior cycles' own catalog notes:
**`nome_mae`/`nome_pai` are dead, commented-out code** (`// if
(this.pedidoAnterior.nome_pai) {...}`) — the live field is a dynamically
repeating `filiacoes` array (`Filiação 1:`, `Filiação 2:`, … up to 6
entries, add/remove buttons), not two fixed parent-name fields.

The correction flow is a single-page "Home" tile menu (`Pages/Home.vue`)
titled "Selecione os serviços que deseja, para solicitar sua Carteira de
Identidade Nacional – CIN," offering six checkbox-gated sections, each
implemented as its own sub-component under `resources/js/Pages/Extendido/`:

| Tile (Home.vue) | Component | Sub-fields this document models |
|---|---|---|
| *Atualizar foto (asterisked: "obrigatória para a solicitação da CIN com atualização") | `Foto.vue` | `photoFile` document |
| *Incluir documentos (asterisked: "A inclusão do CPF é obrigatória") | `Documentos.vue` | `numCPF`, `numCPFResponsavel`, and 7 optional document-number/file pairs (CNH/CNS/PIS/TRE/CTM/CTPS/CIP) |
| Atualizar dados biográficos | `Nome.vue` | `correctedFullName`, `correctedDateOfBirth`, `parentageChanged`, `parent1Name`/`parent2Name`, `maritalStatus`, `civilRegistryNumber`, `civilRegistryCertificateFile` |
| Atualizar assinatura | `Assinatura.vue` | `signatureImageFile` (upload or live signature-pad) |
| Adicionar condições de saúde e deficiências | `Saude.vue` | 5 disability booleans, `observacoesSaude`, `tipoSanguineo`, `doadorOrgaos`, `healthConditionProofFile` |
| *Atualização de contato e endereço (asterisked: "obrigatório possuir um número de celular válido") | `Endereço.vue` | `cellPhone`, address block, `pickupLocationPost`, `seniorCitizenStripe` |

The three asterisked tiles' own prose ("*A atualização da foto é
obrigatória...", "*A inclusão do CPF é obrigatória...", "É obrigatório
possuir um número de celular válido") is the source for modelling `Foto`,
`numCPF`, and the core `Endereço` fields (`cellPhone`,
`postalCode`/`state`/`municipality`/`neighborhood`/`streetAddress`/
`addressNumber`/`pickupLocationPost`) as unconditionally `required: true` —
i.e. every correction/reissuance request always needs a current photo, a
validated CPF, and a current delivery address/phone, regardless of which
other optional sections (biographical data, signature, health) the citizen
also opts into. The judgment call: the live Home.vue template renders all
six tiles as ordinary checkboxes (no `disabled`/pre-checked attribute was
observed in the static template for the three asterisked ones, since that
state is only set by the component's own script logic at runtime, which
this document did not reach live) — so this document infers the "always
required" status for those three tiles' core fields from the form's own
explicit prose, not from an observed disabled/pre-checked checkbox state.

`Pages/Corrigir.vue` (despite its name) is the **success** screen shown
after a request is submitted ("Solicitação realizada com sucesso! ... Você
receberá um SMS com o número da solicitação. Seu pedido será analisado em
até 48 horas..."). `Pages/Pedido/Index.vue` is the actual "Correção de
Solicitação" phone/SMS re-entry screen (matches the live screenshot at
`/pedido` exactly). `Pages/Pedido/Home.vue` is the downstream screen shown
after that phone verification succeeds: a list of IIPR-staff-flagged
"motivos" (reasons), each with an approved/pending icon and an observation
note, with "Corrigir"/"Enviar"/"Sair"/"Cancelar Solicitação" actions — this
is IIPR's internal review/approval loop, not a fixed field schema (the
`motivos` list is dynamically generated per-request by IIPR staff), and is
therefore **not modelled** here (see "What is deliberately NOT modelled"
below).

## Second corroborating source

Beyond the live app and its own compiled source, this cycle also found and
read IIPR's own service-catalog description page (a distinct, independently
maintained CMS page, not the Vue app):
`https://www.policiacivil.pr.gov.br/servicos/Servicos/Identidade-CIN/Solicitar-a-Carteira-de-Identidade-Nacional-CIN-Para-quem-possui-a-CIN-ou-o-RG-expedido-no-Parana-WaowKoDJ`
("Solicitar a Carteira de Identidade Nacional - CIN (Para quem possui a CIN
ou o RG expedido no Paraná)"), `HTTP 200`, no login/CAPTCHA/WAF. Its "O que
é" section states, verbatim: *"Por meio desse serviço, o cidadão que possui
a CIN ou o RG expedido no Paraná, poderá fazer a solicitação on-line da sua
Carteira de Identidade Nacional (CIN). Nesta modalidade, poderão ser
realizadas atualizações ou alterações no cadastro... A CIN não poderá ser
entregue a Procurador quando a solicitação for on-line, pois nessa
modalidade é necessária a validação biométrica do titular para retirar o
documento."* This independently corroborates: (a) the scope is
correction/update of an *existing* record, matching this document's title
and scope; (b) delivery requires the titleholder's own in-person biometric
validation (no proxy/attorney-in-fact pickup), which is why
`pickupLocationPost` is modelled as a physical IIPR post, not a mail-delivery
address; (c) the fee is R$49.31 for anyone who has previously requested a
CIN in Paraná or any other state, and free for first-time requesters — a
fee schedule this document does not model as a `documents[]`
`category: "payment"` entry, since no fee-payment step or amount is
confirmed inside the live app itself (see "What is deliberately NOT
modelled").

Its sibling page,
`.../Solicitar-a-Carteira-de-Identidade-Nacional-CIN-Para-quem-nao-possui-CIN-ou-RG-expedido-no-Parana-dloelrLv`
("...Para quem não possui CIN ou RG expedido no Paraná"), independently
confirms first-time issuance is **in-person-appointment-only** ("poderá
agendar atendimento presencial em um posto de atendimento do Instituto de
Identificação do Paraná") — this document does not model that pathway.
(This supersedes GOV-1616's own citation of a `seguranca.pr.gov.br` page
making the same claim: that exact URL now 404s; the equivalent, current
confirmation lives on this `policiacivil.pr.gov.br` service page instead.)

No further corroborating source (e.g. a downloadable PDF manual or a
`gov.br` federal service-catalog mirror) was found for this Paraná-specific
online flow — the `policiacivil.pr.gov.br` service-catalog page above is
the strongest available second source, consistent with this registry's
house style allowing a single well-verified live source plus one
independent descriptive page when no separate PDF/manual exists.

## What was confirmed against the source

| Source element | Field(s) |
|---|---|
| `Documentos.vue`, "CADASTRO DE PESSOA FÍSICA (CPF)" | `numCPF` |
| `Documentos.vue`, "CPF do responsável pelo menor" (`v-if precisaCpfResponsavel`) | `numCPFResponsavel` |
| `Documentos.vue`, CNH/CNS/PIS/TRE/CTM/CTPS/CIP checkbox+number(+série/UF/emissor)+file blocks | `includeCnh`/`numCNH`, `includeCns`/`numCNS`, `includePis`/`numPIS`, `includeTre`/`numTRE`, `includeCtm`/`numCTM`, `includeCtps`/`numctps`/`seriectps`/`ufctps`, `includeCip`/`numcip`/`emissorcip`/`ufcip`, and their `*ProofFile` documents |
| `Nome.vue`, "Nome:" / "Data de Nascimento:" / "Houve alteração na filiação?" / "Filiação N:" / "Estado Civil:" / "Matrícula da Certidão:" | `correctedFullName`, `correctedDateOfBirth`, `parentageChanged`, `parent1Name`/`parent2Name`, `maritalStatus`, `civilRegistryNumber`, `civilRegistryCertificateFile` |
| `Assinatura.vue`, canvas signature-pad / "Enviar foto da assinatura" | `signatureImageFile` |
| `Saude.vue`, AUDITIVA/FÍSICA/INTELECTUAL/VISUAL/AUTISMO checkboxes, "Observações de saúde:", "Tipo Sanguíneo:", "Doador de Órgãos:", "Laudos Comprobatórios" | `defAuditiva`/`defFisica`/`defIntelectual`/`defVisual`/`defAutismo`, `observacoesSaude`, `tipoSanguineo`, `doadorOrgaos`, `healthConditionProofFile` |
| `Endereço.vue`, "Telefone Celular" / "Cep" / "Estado" / "Município" / "Bairro" / "Logradouro" / "Número" / "Complemento" / "Local de Retirada" / "Incluir informação \"IDOSO\"?" | `cellPhone`, `postalCode`, `state`, `municipality`, `neighborhood`, `streetAddress`, `addressNumber`, `addressComplement`, `pickupLocationPost`, `seniorCitizenStripe` |
| `Home.vue`, six tile checkboxes + asterisked "obrigatória"/"obrigatório" prose | `correctBiographicalData`, `updateSignature`, `addHealthConditions`, and the three unconditionally-required sections (Foto/CPF/Endereço) |

## What is NOT independently confirmed / out of scope

- **First-time CIN/RG issuance.** Confirmed separately, in-person-only —
  see "Second corroborating source" above. Out of scope by design; this
  document's title and description are scoped to correction/update of an
  *existing* Paraná record only.
- **The eligibility/lookup screen itself
  (`num_doc`/`nome`/`data_nascimento`, and the separate `celular`/SMS-code
  re-entry gate on `/pedido`).** These are authentication/record-matching
  mechanics, not data fields of the correction request — consistent with
  every other schema in this registry excluding login/CAPTCHA/OTP mechanics
  (e.g. `br/sp/jucesp/cnpj-registration-dbe`'s VERIFICATION.md explicitly
  makes the same exclusion for gov.br/Brasil Cidadão login).
- **IIPR's internal staff review/approval loop
  (`Pages/Pedido/Home.vue`'s dynamic "motivos" list).** Not a fixed field
  schema — it's a per-request list of flagged items IIPR staff generate
  during their internal review, described in prose ("Seu pedido será
  analisado em até 48 horas... você receberá outro SMS com o número do
  protocolo aprovado ou o motivo da reprovação") but not enumerable as a
  closed field set.
- **The fee-payment step** ("guia de pagamento," R$49.31 for repeat
  requesters). Confirmed to exist by the corroborating service-catalog page
  and by the success-screen prose ("Caso seu pedido tenha sido APROVADO, com
  o número do protocolo recebido, acesse novamente o site do IIPR para
  emissão da guia de pagamento"), but its own payment-collection form is a
  separate, later step this document does not model (no amount/method
  confirmed live).
- **Repeating `filiacoes` beyond the first two entries.** The live form
  supports up to 6 dynamically-added filiação entries; GovSchema v0.3 has no
  array/multi-value field type, so (consistent with
  `br/sp/jucesp/cnpj-registration-dbe`'s single-founder QSA precedent) only
  `parent1Name`/`parent2Name` are modelled.
- **`observacoesSaude`'s full option catalog and `pickupLocationPost`'s full
  post-office catalog.** Both are populated at runtime from external,
  server-provided lists (`observacoesOptions`, `retiradaOptions`) not
  enumerable from the compiled source — modelled as open strings rather than
  closed enums, consistent with this registry's established precedent for
  dropdowns whose full option list isn't statically confirmable (e.g.
  `br/sp/jucesp/cnpj-registration-dbe`'s `registryBodyType`).
- **`municipality`'s full municipality catalog.** Populated per-state from
  an external `optionsMunicipios` list (`{chave, nome}` pairs); modelled as
  an open string, not an enum, for the same reason.
- **The "correcting the name makes updating the signature mandatory" rule**
  (`Home.vue`'s own note: "Ao atualizar o nome torna-se obrigatório a
  atualização da assinatura"). Disclosed in `correctBiographicalData`'s
  description rather than encoded as a `requiredWhen`/`crossFieldValidation`
  rule: GovSchema v0.3's `crossFieldValidation.requirePresent` checks a
  field's mere *presence*, not that a specific boolean field equals `true`,
  so it does not cleanly express "field A `true` implies field B `true`"
  without overreaching the grammar's intent.
- **`seniorCitizenStripe`'s visibility condition** (only shown to applicants
  60+ per their existing record). This is a server-side condition based on
  data (date of birth) this form only sometimes collects (only when
  `correctBiographicalData` is also selected) — disclosed in the field's own
  description rather than forced into a `requiredWhen`/`visibleWhen`
  condition against a field that may not be present.
- **The unusual `cep` mask** (`##.###-###`, i.e. `XX.XXX-XXX` — grouped
  differently from the far more common Brazilian `XXXXX-XXX` CEP display,
  though both are 8 digits). Taken directly and verbatim from the live
  component's own `v-mask` directive, not assumed or corrected, since it is
  what the real form enforces.

## Test run

The `conformance/br/pr/iipr/carteira-identidade-correcao/1.0.0/application-packet.json`
fixture is a fabricated, obviously-synthetic example packet — Camila dos
Santos Ferreira (fake name), the same checksum-valid test CPF used in the
live mock-data run above, a fake Curitiba address — illustrating one
plausible correction request (biographical-data + signature + address
correction, no optional secondary documents or health/disability changes).
It was checked with a from-scratch script (`/tmp/conformance-check-br-pr.mjs`,
re-implementing this document's own `required`/`requiredWhen` `Condition`
grammar per GSP-0013), since no live submission past the eligibility gate
was reachable to cross-check against directly. Result: **0 violations**
across 59 fields/documents (21 collected, 38 correctly not-applicable/
absent). Mutation tests confirmed: (1) flipping `parentageChanged` to `true`
without supplying `parent1Name`/`parent2Name` correctly flags both as
missing; (2) flipping `correctBiographicalData` to `false` correctly drops
every biographical-section `requiredWhen` chain back to not-required; (3)
removing the always-required `cellPhone` value correctly flags it as
missing. The schema itself was also validated against the GovSchema v0.3
meta-schema with both `tools/validate.mjs` and `tools/validate-ajv.mjs`
(both pass); one real authoring bug this caught pre-merge: `signatureImageFile`
was initially miscategorized `category: "attestation"`, which the v0.3
meta-schema forbids from carrying a `constraints`/`mediaTypes` block —
fixed to `category: "supporting-evidence"`.

## Path to a `verified` claim (next step)

To advance to `status: verified`, a reviewer should independently re-fetch
`https://www.rci.pr.gov.br/js/app.js` (confirming the `?id=` hash is
unchanged or, if changed, re-diffing the compiled component source against
this document's field list) and — ideally — walk the live wizard past the
eligibility gate with a real (test) Paraná RG/CPF holder's consent, to
confirm the Home.vue tile-selection behavior (in particular, whether the
three "asterisked" tiles are genuinely rendered `disabled`/pre-checked, a
judgment call this document currently infers from prose rather than an
observed runtime state) and the exact live requiredness of
`numCPFResponsavel`/`seniorCitizenStripe`.

## Re-verification

Per the practice's Cadence, `nextReviewBy` is set to **2027-01-07** (6
months).