modules/bandi-agevolazioni/skills/bandi-agevolazioni/SKILL.md

23.3 KB · Oct 7, 2026 · 00:28 UTC

---
name: bandi-agevolazioni
description: Use when Vera must discover, monitor, match, prepare, or review Italian grants, subsidies, tax credits, or subsidized finance from official sources and client evidence; produces a reviewable opportunity radar or application dossier and never authenticates, contacts clients or signs; portal submission requires explicit approval of the final application.
---

# Bandi e agevolazioni

## Jurisdiction and Geneva

For a CH-GE mandate, read `references/geneva.md` before the steps below. It specifies the Geneva input, source and output adaptations within this existing function. Choose governing jurisdiction independently of output language; the ordinary Italian path remains available for IT.

Before any opportunity research, read `references/source-first-discovery.md`
and `references/institutional-discovery.md` completely. This method applies in
Codex and ChatGPT, including a public scan without a client portfolio. Follow
`references/institutional-discovery.md` for capability checks and the auditable
chat-only route when local execution is unavailable. Do not replace the method
with generic searches or claim local validation ran in chat.

Operate one of two connected stages:

1. a private opportunity radar that builds opaque company profiles, plans and
records official-source checks, monitors opportunity lifecycle, matches one
opportunity to one or more clients in both directions, and prioritizes
professionally reviewable opportunities; or
2. one source-bound application dossier inside a running Studio Archive
engagement after an opportunity has been selected.

Treat source relevance, compatibility, lifecycle meaning, economic assumptions,
eligibility, exclusion, eligible-cost, document, form, and narrative conclusions
as proposals until the responsible professional reviews them.

## Output location

Never write run outputs inside this Git workspace or a published folder. Stage A
uses one explicitly authorized, owner-only studio-radar workspace bound to its
exact local path; it is not a portable client run. Stage B uses only the exact
private Studio Archive client-run output described below.

## Hard boundaries

- Never invent eligibility, exclusion, eligible-cost, deadline, document, or
form requirements.
- Never use deterministic keywords to select the governing framework or decide
the meaning, applicability, or authority of a source.
- Never request, store, replay, or export credentials, SPID/CIE/CNS material,
cookies, tokens, one-time codes, delegations, or signatures.
- After explicit approval of the project and portal preparation, follow
`references/portal-preparation.md`: fill ordinary fields, upload approved
attachments and save a draft in the user-authenticated application.
- Never authenticate, accept declarations, sign or pay. Submission is allowed
only after explicit user approval of the exact final application under
`references/portal-preparation.md`, never from project approval alone.
- Never use `ready` as a synonym for eligible or accepted. Keep documentary
readiness separate from the assessment outcome. `ready_to_file` is always
false.
- Treat an official FAQ as clarifying evidence whose effect requires review;
never let it silently override a formal act.
- Keep OCR-derived facts at `verify` until the source image is visually checked.
- Never describe a source-plan coverage ratio as the probability that all
opportunities were found. It measures only checked sources in the reviewed
plan.
- Never begin semantic web discovery for a recent-opportunity scan before every
reviewed priority source has been directly attempted for the requested
window. Disclose every failed, unavailable, missing or unreviewed priority
source instead of calling the scan complete.
- Never place client identity, financial data, project narrative, quotations,
or declarations in public discovery queries. Portfolio radar profiles use
opaque client references.
- Never contact a matched client automatically. The professional owns whether,
when, and how to contact the client.

Reserve explicit approval for an external, destructive, approval-sensitive, or
material step. Ordinary local evidence inspection and deterministic validation
inside the already selected run do not require a separate confirmation.

## Codex-Native Run UX

1. Show a checklist covering dependencies, Run Intake, source selection,
workbench drafting, professional review, validation, and packaging.
2. Show a Run Intake table with the opaque client reference, call identifier,
reference date, bound input and output paths, source-set revision, and
external-research posture.
3. Use a Decision Table for unresolved source authority, applicability,
requirement meaning, eligibility, exclusions, costs, missing evidence,
conflicting facts, form fields, narrative claims, and portal guidance.
Generate it from the actual inputs; do not offer named classifications,
authorities, or legal conclusions unless the facts cue them.
4. Ask only about material choices that change the case, governing source,
professional conclusion, destination, or authorized write scope.
Ask only those unresolved choices in chat and wait only when an answer would
materially change the scope or authorized action.
5. Before a long or write-heavy stage, show an execution checkpoint with the
bounded inputs, private output path, intended command, and expected files.
6. End with an Artifact Card listing source count, disposition, validation,
stale or missing reviews, blockers, outputs, and the next authorized-person
action.

Default output policy: produce the ordinary private JSON, audit, and Markdown
review package when the tooling can do so. These are not choices to propose.
Open the package's `review_dossier.html` first: it presents the recorded case
summary, costs, documents, proposed assessments and project draft in the run's
language, with links to source excerpts and detailed records. It is generated
by the native packager from the same validated snapshot and included in the
manifest. Keep `review_dossier.md` and the JSON/audit files as detailed working
records. The report does not infer new eligibility conclusions or review
decisions. Check the recorded action section before describing portal activity,
signatures or submission.
When useful, save the visible run summary as `codex_run_review.md` beside the
package. Never edit plugin source or generated ZIPs during a customer case run.

## Client engagement gate (Stage B only)

Select one Studio Archive client and engagement, import the official sources
and client evidence as immutable receipts, then prepare and start workflow
`bandi-agevolazioni`. Pass the returned `client_engagement_path` to every
mutating command. Write only to the exact run output directory.

After the outputs are reviewed, finalize every file with a stable artifact ID,
purpose, audience, and media type; then complete the run. Record `failed` or
cancel an abandoned run instead of treating partial files as a result.

## Workflow

Read `references/product-thesis.md`, `references/workflow-method.md`,
`references/opportunity-radar.md`, `references/source-first-discovery.md`, and
`references/implementation-status.md` completely before interpreting sources,
requesting a model contribution, or editing either workbench. Use
`references/acceptance-matrix.md` when reviewing or releasing the workflow.

### Stage A — opportunity radar

Initialize a private studio radar. `single_client` accepts at most one opaque
profile; `portfolio` supports reverse matching from a newly observed
opportunity to several opaque client references:

```bash
python scripts/opportunity_radar.py \
--workspace <private-radar-workspace> \
initialize \
--radar-id <stable-id> \
--workspace-id <stable-private-workspace-id> \
--reference-date YYYY-MM-DD \
--scope single_client|portfolio \
--authorized-by <operator> \
--retention-owner <firm-or-professional> \
--confirmed-by-user
```

Initialization records an asserted-not-authenticated authorization receipt and
binds the radar to that exact non-Git, non-published directory. The professional
owns its local retention. Moving the radar or changing its path fails closed;
create a new explicitly authorized workspace rather than editing its receipt.

Use the model semantically to propose profile facets, a jurisdiction- and
client-specific official-source plan, source-backed opportunities and matches.
Register opaque profile evidence receipts first with `record-evidence`; every
document-observed facet must close to a same-client receipt. Record each
proposal with exact provider, model, prompt-template and operator provenance
using `record-profile`, `record-source`, `record-opportunity`, and `record-match`.
Client-evidence interpretation must use one fresh, operator-attested model
session reference for that client; code rejects reuse of that reference for a
different client. Public-source planning, discovery, and portfolio matching
must run in a separate model session that receives only the opaque profiles and
public opportunity material, never the clients' raw documents; code rejects
reuse of a client-evidence mapping session reference in either direction.
Session references are local provenance, not provider-authenticated session
identity.
Record actual source checks separately with
`record-source-check`; a planned source is not checked merely because it is in
the plan. Use `record-scan` for resumable monitoring runs and preserve lifecycle
history rather than overwriting an earlier status.

For recent discovery, treat the reviewed source plan as a persistent priority
registry. Each source proposal must state `discovery_role`, `source_surface`,
`territories`, `categories`, and `act_families`; those fields remain model-led
and professionally reviewed. For each temporal scan, use model reasoning to
propose an exact query-scoped selection from confirmed registry entries. The
selection must declare one `covered` or `gap` claim for every territory and
category in the generic query context, cite the selected source IDs and explain
the semantic rationale. Code checks only exact claim presence, IDs and roles; it
does not match territory or category strings to publishers.

Start the scan with exact selection provenance, review the selection explicitly,
then render its direct-source worklist:

```bash
python scripts/opportunity_radar.py \
--workspace <private-radar-workspace> \
record-scan \
--input <running-scan.json> \
--idempotency-key <stable-scan-start-id> \
--origin model_suggested \
--provider <provider> \
--model <exact-model> \
--prompt-template-version bandi-source-selection-v1 \
--model-session-ref <fresh-operator-attested-session-ref> \
--recorded-by <operator>

python scripts/opportunity_radar.py \
--workspace <private-radar-workspace> \
review \
--scope scan_source_selection \
--target-id <scan-id> \
--decision accepted \
--reviewer-id <reviewer> \
--reviewer-role commercialista \
--confirmed-by-user \
--idempotency-key <stable-selection-review-id>

python scripts/opportunity_radar.py \
--workspace <private-radar-workspace> \
worklist \
--scan-id <scan-id>
```

Inspect every priority URL directly across the requested window, including
all Gazzetta Ufficiale issue summaries in the window, ministerial and programming
decrees, and relevant DGR, DDR, BUR issues, annexes, FAQs and amendments.
For an `official_gazette` check, pass `--issue-inventory-input <inventory.json>`
using the contract in `references/institutional-discovery.md`; a checked source
requires complete declared issue coverage. Record each check
against the running scan; optionally pass a cursor JSON containing the latest
stable publication ID, publication date or official URL:

```bash
python scripts/opportunity_radar.py \
--workspace <private-radar-workspace> \
record-source-check \
--source-id <source-id> \
--check-id <stable-check-id> \
--scan-id <scan-id> \
--check-status checked \
--checked-at <ISO-date-time> \
--window-start YYYY-MM-DD \
--window-end YYYY-MM-DD \
--result-count <count> \
--cursor-input <optional-cursor.json> \
--idempotency-key <stable-check-operation-id>
```

Review each check, then use semantic web research only as a complementary last
phase. Finish the same scan with a terminal payload. `complete` is rejected
unless the selection is confirmed, every query dimension is declared covered,
and the sealed coverage snapshot resolves every selected priority source.
Otherwise record `partial` or `failed` and report the exact scope gaps and
unverified source IDs. A rejected registry proposal outside the reviewed scan
selection never blocks that scan. A source cursor accelerates delta detection
but never replaces the stated historical window. Read
`references/source-first-discovery.md` for the complete contract.

Review each evidence receipt, source-plan entry, source-check result, profile,
opportunity and match explicitly. `source` confirms plan relevance;
`source_check` separately confirms the exact observed check result:

When confirmed profile or opportunity facts change, supply an append-only
`revision_event` with a stable ID, observed time, rationale and referenced
evidence or official sources. The changed item and dependent matches return to
`proposed`; prior review events remain historical.

Render `opportunity_radar_review.md` with `report`. After the exact evidence,
profile, checked source-plan entries, check results, opportunity and match are
confirmed, use `handoff` to write one selected match inside the radar workspace.
The handoff embeds only that client's evidence and sources and carries
recomputable selection and source-entry hashes. Import that JSON as a source
into the chosen client's new Studio Archive `bandi-agevolazioni` engagement and
register it with source type `opportunity_handoff` and authority role
`mechanical`. Registration revalidates schema, hashes, client identity and
reference closure. The handoff selects work for instruction; it is not evidence
of eligibility and does not replace the exact official call materials.

### Stage B — application instruction

1. Run `python scripts/check_dependencies.py` from the component root. The
declared `jsonschema` dependency is required for exhaustive runtime contract
validation; do not install it at runtime.
2. Initialize the bounded drafts:

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

3. Register each exact selected input without copying or fetching it:

```bash
python scripts/register_source.py \
--output-dir <run-output> \
--client-engagement <client_engagement_path> \
--source <bound-input-file> \
--source-id SOURCE-001 \
--source-type call \
--title "Official call title" \
--issuer "Issuing authority" \
--authority-role primary \
--selected-by <reviewer>
```

After professional source selection, record amendments, supersession,
clarification, implementation, and incorporation links mechanically:

```bash
python scripts/link_sources.py \
--output-dir <run-output> \
--client-engagement <client_engagement_path> \
--source-id AMENDMENT-001 \
--kind amends \
--target-source-id CALL-001
```

4. Request one bounded semantic contribution at a time. Source interpretation
and requirement drafting may read only the selected official sources.
Evidence mapping may read only the selected client evidence needed to create
the structured facts and document map. Every contribution uses a fresh,
operator-attested model session reference. Later assessment, cost, form,
narrative, consistency, red-flag, authority-simulation, and workflow tasks
receive only their task-specific, reference-closed structured packet; they
do not reuse the earlier evidence-reading session.

The packet builder does not truncate the first arbitrary records. It follows
exact subject and artifact references, reports included and omitted counts
and bytes, and fails closed when the complete closure exceeds its limits.
The model must then return `INSUFFICIENT` with a concrete context request;
the operator or professional chooses exact IDs from each over-limit
collection and reruns them, together with the task subjects they need, in
another fresh session. An exact ID scopes only its own global-root
collection; every other global-root collection stays complete. Do not
silently infer from omitted material or split a holistic
consistency/authority review automatically.

The intake applicant object and local paths are not copied by default, but
professionally relevant facts and excerpts may still identify the applicant;
there is no automatic anonymization. Create the packet without mutating the
case:

```bash
python scripts/intelligence_workflow.py \
--output-dir <run-output> \
--client-engagement <client_engagement_path> \
packet \
--model-session-ref <fresh-operator-attested-session-ref>
```

Retain the exact packet delivered to the model. Compute its SHA-256 with
`intelligence_contract.intelligence_packet_hash(packet)` (UTF-8 JSON with
`ensure_ascii=False`, `sort_keys=True`, and separators `(',', ':')`). The
required digest binds recording to that supplied packet. Repeat the same
`--task`, every `--subject-id`, and `--model-session-ref` used for packet
creation. Recording fails without mutation if that scope or packet content
has changed; regenerate and obtain a new response after input changes. This
binding does not authenticate provider execution or prove what the provider
received.

Record the exact response and exact provider/model/template identity as a
non-authoritative `MODEL_SUGGESTED` run:

```bash
python scripts/intelligence_workflow.py \
--output-dir <run-output> \
--client-engagement <client_engagement_path> \
record \
--model-output <strict-output.json> \
--expected-packet-sha256 <sha256-of-exact-supplied-packet> \
--provider <provider> \
--model <exact-model> \
--prompt-template-version bandi-intelligence-v2 \
--model-session-ref <same-ref-used-to-create-this-packet> \
--recorded-by <operator> \
--idempotency-key <stable-request-id>
```

Codex/model reasoning may propose atomic requirements, facts, assessments,
document checklist items, expenses, form fields, narratives, consistency
checks, issues, and an adversarial authority-review simulation. It cannot
update the workbench until a professional explicitly accepts that exact run:

```bash
python scripts/intelligence_workflow.py \
--output-dir <run-output> \
--client-engagement <client_engagement_path> \
decide \
--intelligence-run-id INTEL-000001 \
--decision accepted \
--reviewer-id <reviewer> \
--reviewer-role commercialista \
--confirmed-by-user
```

`rejected` and `returned` are also explicit terminal decisions. Accepted
contributions enter `application_workbench.json` only as `proposed`; they
never overwrite confirmed or blocked work. Proposed `ready` or
`not_applicable` readiness is normalized to `verify`: neither can certify
professional review, and the proposed outcome and rationale are preserved.
Any change to intake, sources, or
workbench makes an undecided run stale. Deterministic scripts validate shape,
identity, references, exact arithmetic, review hashes, status consistency,
and prohibited portal controls; they do not interpret the call.
5. Record explicit professional decisions mechanically:

```bash
python scripts/record_review.py \
--output-dir <run-output> \
--client-engagement <client_engagement_path> \
--scope source_baseline \
--decision accepted \
--reviewer-id <reviewer> \
--reviewer-role commercialista \
--confirmed-by-user
```

Review scopes are `source_baseline`, `requirements`, `assessments`, and
`dossier`. A changed bound artifact invalidates the prior review hash.
Use `--confirmed-by-user` only after the user explicitly confirms that exact
scope and decision. The local reviewer ID and role are asserted metadata,
not authenticated identity; the dossier states this boundary and remains
for authorized professional review.
6. Validate and package the private review dossier:

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

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

7. Show the professional the exact readiness/outcome matrix, missing evidence,
unresolved interpretations, red flags, draft form fields, and narrative
claims. Do not hide negative or uncertain findings in polished prose.
8. For approved portal preparation, read `references/portal-preparation.md`
and use available host browser tools. Project approval and the request to
compile authorize ordinary fields, approved attachments and draft saving;
do not ask again for each field. Authentication, declarations, signature,
and payment remain manual. Submission requires explicit final approval.

## Status contract

Readiness is `ready`, `missing`, `verify`, or `not_applicable`. Assessment
outcome is separately `satisfied`, `not_satisfied`, `uncertain`,
`not_applicable`, or `not_assessed`. `not_applicable` requires a reviewed
rationale. A conclusive negative assessment may therefore be documentary
`ready` while making the dossier unsuitable for filing.

## Deterministic boundary

Use deterministic code only for mechanically verifiable work: exhaustive JSON
Schema and ID validation, exact hashes, path containment, source/reference
closure, workspace and handoff path binding, review freshness, source-plan
check ratios, source-registry revision binding, exact query-dimension claim
closure, query-scoped selection reference closure, temporal-window containment,
direct-before-semantic execution order, cursor preservation, scan completion
coverage, chronological lifecycle-history preservation, task-to-input
allowlists, reference-closed packet construction, complete packet inventory and
byte/item limits, non-reuse of operator-attested model-session references across
Stage B contributions, client-isolated radar mapping-session references,
separation of radar matching from client-evidence sessions, blocking of
unmistakable credential/session values, exact
economic range subtraction from supplied assumptions, the versioned
`exact_decimal_compare` and `exact_date_compare` rule families after their
inputs and outcome mapping are professionally confirmed, status invariants,
review hash binding, and packaging. Keep source-plan selection, source
relevance, opportunity meaning, compatibility, lifecycle meaning, economic
assumptions, recommended action, source authority, requirement meaning,
eligibility, exclusions, cost classification, narrative judgment, conflict
significance, and simulated-authority review model-led and professionally
reviewed.

## Plugin Improvement Feedback

Keep the improvement note local to chat or run artifacts. Do not submit it to
Mparanza automatically. When this workflow runs through Vera, use Vera's
consent-based Plugin Improvement Feedback process for any transmission.

SHA-256: 100b0e41af8f580ad3c21706f1eb9f5943e7d6ce18f0a14b5c008f7ee039f93d