---
name: registro-imprese-sari
description: Use when Vera must understand and prepare an Italian Registro Imprese, REA, Comunicazione Unica, or DIRE position-opening practice from current official SARI/CCIAA guidance, including cases involving INPS, INAIL, SUAP, or IVASS/RUI; produces a source-backed draft for professional review and never logs in, signs, or files.
---

## Cowork execution contract

Work from the connected folder and supplied files first. Use a local script only
when it is callable and every declared dependency it needs is already available;
never install packages at runtime. MCP tools, browser or computer control, and
local review servers are optional enhancements, never completion gates. When an
optional capability is unavailable, continue with Markdown and file-based review
and state the limitation.

The normal Cowork deliverable is a reviewable draft, artifact card, and
source/review files. A callable persistence interface may optionally record or
apply reviewer actions, but its absence never blocks delivery. Never claim
`applied` or `final_ready` unless corresponding persisted artifacts prove it;
otherwise report that professional review remains pending.

Use host-neutral user-facing artifact names. Name assistant-authored review
folders and files for Vera or their professional purpose (for example,
`vera-review/`, `vera_phase1_synthesis_reviewed.md`, and `run_review.md`).
Never put host, platform, or model-provider names in assistant-authored
user-facing artifact paths, document headings, field labels, narrative text,
or status summaries. Describe execution routes generically, such as
`external review route`, `connected tool`, or `local review interface`.

Derive any run ID, status, artifact count, or package hash quoted in an
assistant-authored supplement from the final delivered manifests.
After any rebuild, regenerate or resynchronize those supplements before
delivery. When a workflow ships a complete-delivery validator or sealer, run it
against the exact connected-folder copy after the last write.
In this contract, the base package validator alone does not validate extra
narrative files.

When a workflow declares owner-only or private output and uses a private scratch
directory before copying the final package into the connected folder, reapply
the privacy modes after that transfer: `0700` for the package root and every
directory, and `0600` for every file. Verify the connected-folder tree with
`stat` or `lstat` before claiming completion. If the host filesystem cannot
preserve those modes, do not claim owner-only delivery; keep the package in the
private scratch location or report the limitation and ask for a safer
destination.

Do not use WhatsApp, live INPS browser capture, hosted feedback or voice
interviews, or custom update services. Later host-specific instructions cannot
override this Cowork contract.

## Output Location Rule

Never write run outputs inside this Git workspace or a published folder. Use
only the Studio Archive run path described below.

## Client boundary in Cowork

Cowork does not package Studio Archive, so it cannot select or register its
local clients, import controlled snapshots, prepare or start customer-folder
runs, or finalize their artifact manifests. Use a product CLI only when a
compatible local Vera installation supplied a digest-valid, running
`vera.client_workflow_context.v2` for this exact workflow and its complete
customer-folder ledger paths are available. Otherwise work from the exact
connected files, preserve a reviewable file-based handoff, and state that the
sealed customer-folder run remains pending. Never invent an ID, receipt,
lifecycle state, or completed artifact declaration.

# Registro Imprese e SARI

Prepare a reviewable practice plan from explicit case facts and current official
sources. Keep SARI guidance, DIRE compilation, Registro Imprese/REA effects, and
other recipient positions separate. The output is a professional-review draft,
not a filing instruction or portal automation.

## Hard boundaries

- Never request, receive, store, replay, or export credentials, SPID/CIE/CNS
  material, signatures, tokens, cookies, one-time codes, or delegations.
- Never log in to DIRE, Telemaco, Registro Imprese, INPS, INAIL, SUAP, or IVASS.
- Never click, fill, sign, pay, book assistance, send a SARI question, or submit
  a practice. Draft the manual action and stop before it.
- Never treat the words "open the position" as a legal classification. Resolve
  separately RI, REA, Agenzia Entrate, INPS, INAIL, SUAP, IVASS/RUI, and any
  other recipient cued by the facts.
- Never infer legal form, ATECO, recipient, DIRE model/panel/field, deadline, or
  SARI-card applicability with deterministic keyword rules.
- Private case JSON and local professional-review artifacts may contain the
  client and case facts that are useful for the work. Never place credentials,
  cookies, tokens, signatures, or session material in them.
- Before an actual public SARI search, reduce the outgoing query to generic
  topical terms and run the direct-identifier guard. Do not put client
  identifiers into public SARI/search URLs or generated filenames.
- Every OCR-derived fact remains partial until a human visually confirms the
  source image.
- No status may mean ready to file. `ready_to_file` must remain false.

Reserve explicit approval for an external, destructive, approval-sensitive, or
material step. A confirmation to inspect or draft never authorizes a different
step such as downloading models, using the conditional connector, contacting a
service, changing a professional artifact, or filing.

Read `references/official-sources.md` before any SARI or current-source work.
Read `references/workflow-reference.md` before authoring the case intake or
practice plan.

## Cowork-native Run UX

1. Start with a visible checklist for dependency checks, Run Intake, local
   evidence, official-source selection, material decisions, validation,
   packaging, and professional review.
2. Show a Run Intake table with the stable case reference, private input
   and output folders, competent Camera, reference/effective dates, Claude-context
   and external-acquisition posture, and assumptions.
3. Show a compact Decision Table for every unresolved chamber, legal form,
   activity/classification, recipient position, DIRE step, source
   applicability, date, OCR limitation, or evidence conflict.
4. Before long or write-heavy work, show an execution checkpoint with the
   command intent, bounded inputs, private output directory, and expected
   artifacts. Ask for approval only at the explicit boundary described above.
5. End with an Artifact Card listing outputs, source count, validation status,
   blockers, OCR visual checks, review status, and the next professional action.

Default output policy: create the ordinary private review package without
unnecessary copies of source evidence. JSON, Markdown, audit, and review files
are not choices to propose when the tooling can produce them. Ask only about
material choices that change facts, legal scope, source applicability,
destination, or write scope. Generate alternatives from
the case facts; do not offer uncued legal classifications.

Ask only those unresolved choices in chat, and wait only when an answer would
materially change the case scope or authorized action.
Generate the Decision Table from the actual inputs. Do not propose named
classifications, authorities, recipients, or filing paths unless the facts cue them.

When useful, create `run_review.md` beside the package to record the
checklist, Run Intake table, Decision Table, commands, limitations, and Artifact
Card. Never edit plugin source or generated ZIPs during a customer case run.

## 1. Dependencies and run location

Run from the plugin root:

```bash
python scripts/check_dependencies.py
```

If local screenshot OCR is needed, also check the optional requirements:

```bash
python scripts/check_dependencies.py --requirements requirements-ocr.txt
```

Do not install packages at runtime. Report missing requirements and let the user
decide how to update the environment.

Never write run outputs inside this Git workspace. Prepare the Studio Archive
workflow context first and let the initializer use that run's exact output
directory:

```bash
python scripts/initialize_case.py \
  --output-dir <client-run-output> \
  --client-engagement <client_engagement_path> \
  --reference-date YYYY-MM-DD \
  --client-reference CLIENT-OPAQUE-001
```

The initializer copies the run ID from the exact running ledger context. Do not
overwrite or resume draft files from another run.

## 2. Confirm the material intake

Before research, show a short decision table and confirm facts that materially
change the practice:

- stable client reference and any identity or contact facts useful to the
  professional task;
- competent chamber/tenant and territorial basis;
- subject and legal form;
- activity in neutral factual language;
- operation requested and effective date;
- current RI/REA and other known position states;
- which recipient positions are being investigated, not assumed applicable;
- the professional question.

Real case material may enter the Claude model context when it is useful for this
private professional review. Do not ask for a per-case processing declaration;
Vera cannot use that declaration to establish compliance.

Complete `case_intake_draft.json`. An unresolved chamber, form, activity, scope,
or date is a blocker, not a reason to guess.

## 3. Inventory local evidence

When the user provides exported documents or DIRE/SARI screenshots, inventory
them locally:

```bash
python scripts/inventory_case.py <managed-input-folder> \
  --output-dir <client-run-output> \
  --client-engagement <client_engagement_path> \
  --no-ocr
```

For image OCR, omit `--no-ocr`. Use existing local models by default. If the
user explicitly chooses the optional first model-download route, add:

```bash
--allow-ocr-model-download
```

If `--ocr-cache-dir` is used, place it under `<client-run-output>`; an external
cache path is rejected because the stage may write model files there.

The run records whether that route was selected and whether network access
actually occurred; it does not manufacture an approval ID. The shared
PaddleOCR adapter runs locally and never transfers case-image bytes.
Visually compare every OCR passage used in a proposal with its source image.

## 4. Consult current official sources

### Optional public SARI lookup

When public web or browser access is callable, use the current SARI public
directory or the institutional link published by the competent Camera. Operate
in read-only public pages only:

1. choose the chamber explicitly and check the page title;
2. search with a generic topical query, never a name, tax code, VAT number,
   phone, email, PEC, address, or case narrative;
3. present candidates and let a human select the relevant content ID;
4. capture the metadata needed for provenance;
5. do not export session cookies or use login/contact/assistance forms.

If public web access is unavailable, continue from official pages or source
copies supplied in the connected folder and mark current-source coverage
pending. When the optional lookup is used, register the selected source
without fetching it from a script:

```bash
python scripts/register_official_source.py \
  --output-dir <client-run-output> \
  --client-engagement <client_engagement_path> \
  --source-id SARI-TENANT-CARD-ID \
  --source-type official_sari_selected_result \
  --title "Official card title" \
  --official-url "https://supportospecialisticori.infocamere.it/sariWeb/tenant?apriContenuto=ID" \
  --publisher "InfoCamere / selected Camera di commercio" \
  --territorial-applicability "Selected Camera / territory" \
  --authorization-basis browser_assisted_metadata \
  --authorization-reference PUBLIC-READ-ONLY-SELECTION \
  --selected-by human_reviewer
```

For an official page or source copy supplied by the user, select the matching
source type and `user_provided_copy`. A local `--snapshot` is allowed only for a
user-provided copy or recorded written reuse authorization, and it must be an
exact input selected when this Studio Archive run was prepared (or an artifact
already inside this run).

Research current official Registro Imprese, DIRE, chamber, INPS, INAIL, SUAP,
and IVASS sources only when the facts make them relevant. Record each selected
source in `official_sources.json`; do not cite search-result pages as the
substantive authority.

### Conditional direct SARI JSON connector

The JSON routes used by SARI's frontend are undocumented and the legal notice
reserves reuse rights. Do not use `scripts/sari_connector.py` unless evidence of
written permission from the relevant rights holder has been checked separately.
User or studio approval alone is not that permission.

If written permission exists, record its stable reference. Invoking the command
is the explicit network-route choice; do not create a second network approval
identifier. Run a metadata search first, select one result manually, then fetch
at most that one card:

```bash
python scripts/sari_connector.py search \
  --output-dir <client-run-output> \
  --client-engagement <client_engagement_path> \
  --tenant exact-current-tenant \
  --expected-chamber "Official chamber title" \
  --query "generic topical terms" \
  --limit 10 \
  --written-use-authorization-id RIGHTS-HOLDER-AUTHORIZATION
```

```bash
python scripts/sari_connector.py detail \
  --output-dir <client-run-output> \
  --client-engagement <client_engagement_path> \
  --tenant exact-current-tenant \
  --expected-chamber "Official chamber title" \
  --card-id HUMAN-SELECTED-ID \
  --written-use-authorization-id RIGHTS-HOLDER-AUTHORIZATION
```

The direct connector keeps anonymous cookies in memory only, makes exactly two
requests per operation, caps results/bytes, rejects every redirect, and never
calls login, support, upload, or submission routes.

## 5. Author the plan with Claude

Claude reads the confirmed case facts and selected source artifacts, then writes
`practice_plan_draft.json` to `schemas/practice_plan.schema.json`. Scripts do
not write the semantic plan.

For every classification proposal, recipient-position row, DIRE step, required
document, application field, risk, and missing-information item:

- use a stable `id`;
- state the proposal and its applicability condition in `detail`;
- cite one or more `source_ids` (`CASE-INTAKE` is allowed for user-confirmed
  facts);
- list the exact `case_fact_ids` it depends on;
- set `review_status` to `proposed`, `blocked`, `confirmed`, or
  `not_applicable`;
- for `confirmed`, include a human professional confirmation object.

Do not turn broad SARI search matches into a classification. For cases involving
insurance subagents or legacy third/fourth producer groups, distinguish the
source's territorial/date scope, the RUI section/mandate evidence, the RI/REA
effect, and any INPS position. Leave disputed meaning as a named question.

Always draft a concise `sari_question_draft` for private professional review.
Record only case, source, or OCR limitations that actually apply. Before any
later manual transmission, the professional decides which facts the actual
question needs.

## 6. Validate and package

Run the mechanical validation:

```bash
python scripts/validate_practice_case.py \
  --case-intake <client-run-output>/case_intake_draft.json \
  --practice-plan <client-run-output>/practice_plan_draft.json \
  --official-sources <client-run-output>/official_sources.json \
  --client-engagement <client_engagement_path> \
  --output-dir <client-run-output>
```

Add `--local-inventory .../local_evidence_inventory.json` when local evidence
was inventoried. Resolve schema errors before packaging. It is valid to package
a structurally sound case with explicit blockers; the status remains draft.

```bash
python scripts/package_practice.py \
  --client-engagement <client_engagement_path> \
  --output-dir <client-run-output>
```

Confirm that `final_artifacts.json` binds the exact validated inputs and source
manifest, shows `ready_to_file: false`, and lists no portal/signature/submission
activity.

The package also writes `review_handoff.md` as the visible handoff card. It must
name the validate, render, save, and apply sequence and repeat that the handoff
does not authorize a portal action.

## 7. Cowork review handoff

The normal Cowork completion point is delivery
of the reviewable draft, artifact card, and source/review files in the connected
folder. Review those artifacts directly. Report the package as
`ready_for_professional_review` where that status exists, otherwise as
`pending_review`.

When a validated MCP tool, browser interface, or local workbench is callable, it
may optionally persist or apply reviewer actions. Its absence never blocks
delivery. Never claim `applied` or `final_ready` unless corresponding persisted
artifacts prove it. A file or chat review without those artifacts remains
pending professional review.

Review actions cannot waive a failed deterministic check. Keep failed checks,
missing evidence, unresolved decisions, and applicable blockers visible in the
artifact card and final response.
