Update to Vera

{
  "name": "datev-invoice-start",
  "description": "Avviare o riprendere una prova reale delle fatture passive in DATEV nativo Windows con la procedura ECONS già nota, controllo nativo dell'host quando disponibile, progressi locali, report per cliente e richiesta di adattamento revisionabile.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 271
    }
  ],
  "skill_md_contents": "---\nname: datev-invoice-start\ndescription: Avviare o riprendere una prova reale delle fatture passive in DATEV nativo Windows con la procedura ECONS già nota, controllo nativo dell'host quando disponibile, progressi locali, report per cliente e richiesta di adattamento revisionabile.\n---\n\n# Prima prova DATEV su Windows\n\nAfter substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../vera/SKILL.md`. The explicit adaptation request below uses its capability-request route; do not add a survey or invent a failure.\n\nUse this route before generic teaching/onboarding or Browser Automation when the\noperator wants to try the known invoice procedure on native DATEV. This is a\nbounded real-work adaptation session, not a multi-workflow tutorial. Onboarding\nis optional and never blocks this route. If the user explicitly requests a\ntutorial, honor its local-only feedback boundary instead of submitting a CR.\n\nResolve the Vera root as `../..` from this skill directory. Resolve the shared\nmodule as `<Vera>/modules/browser-automation` in an installed package, otherwise\n`<Vera>/../browser-automation` in repository source. Read its\n`references/passive-invoice-procedure.md`, `references/batch-review.md`,\n`references/teaching-checkpoint.md` and `references/development-request.md`.\nThese references supply professional procedure, local persistence and handoff;\nthey do not make DATEV a browser application. Do not run ECONS acquisition,\n`tab.playwright`, browser discovery or capability promotion against DATEV.\n\nThe current procedure is already known. Francesco is a new operator, unrelated\nto the earlier TeamSystem/Agenzia tester. Never assume shared conversations,\nfiles, credentials, exclusions, client tax treatment or screen profiles. Do not\nask him to explain the accounting procedure again or supply code, selectors,\ncoordinates, JSON, an automation framework or a ZIP.\n\n## Start and establish the environment\n\n1. Say in Italian: “Uso la procedura già predisposta per le fatture passive.\n   Verifico DATEV e gli strumenti disponibili, poi lavoriamo su una sola fattura\n   e ti lascio il riepilogo con quanto resta da controllare.”\n2. Run `<module>/scripts/check_installation.py` and\n   `<module>/scripts/check_dependencies.py` with Vera's existing managed Python\n   before helpers. Read the version of this active Vera installation. No\n   runtime package installation, standalone UI driver or second Python environment.\n3. Reuse the run path from the current conversation. For a new operator choose\n   a fresh ordinary private local directory under the authorized working folder,\n   outside Git, public folders and synchronized developer exports. Create its\n   parent if needed within host permissions. Call\n   `<Vera>/scripts/datev_starter.py start <fresh-run>`. Save the returned path\n   in the conversation and link `report_path`. The supplied PROCEDURA.md is\n   authored guidance; zero recorded steps is not an invoice acquisition.\n   If filesystem access fails, state that progress was not saved, retain the\n   in-chat recap and exact error, and request only the missing local access.\n4. Inspect current supported host tools and their documentation. With\n   `mcp__cua_repl`, follow its first-call rule, obtain the enabled app inventory,\n   then select the exact DATEV app using the actual reported ID and documented\n   `cua.getApp`. Read its current state before acting. Never invent an executable\n   name, AX index, API, window binding or a success result. A listed tool or\n   Windows shell alone is not proof that the DATEV window can be observed.\n5. Establish product/edition and version, Windows version, local installation\n   versus RDP/Citrix/VM, and which desktop contains DATEV. Read About or supplied\n   installation facts where available. Ask only missing facts in one ordinary\n   question, e.g. “Quale prodotto e versione DATEV usi, e si apre direttamente\n   su questo PC o dentro una sessione remota?” Do not request login details.\n6. The primary OpenAI documentation reviewed on 2026-09-15 supports Computer Use\n   on macOS and Windows in supported regions; availability still depends on\n   the installed host and policy. On Windows the app must be visible on the\n   active, unlocked desktop and Computer Use takes foreground input. Check\n   current tool documentation, not this dated statement alone. If Computer Use\n   is missing, give one supported setup instruction: Plugins → Computer Use →\n   Install/Enable, then Settings → Computer use to review app access. Let the\n   operator handle permission prompts and login. Do not change allowlists,\n   install UIAutomation/pywinauto/AutoHotkey, elevate privileges, inspect session\n   stores or bypass denials. Do not treat a browser inside an RDP portal as DOM\n   access to DATEV. A remote canvas without supported reliable observation is a\n   specific binding gap.\n\nSource: https://learn.chatgpt.com/docs/computer-use and\nhttps://learn.chatgpt.com/docs/enterprise/chatgpt-work-local-security#locked-devices.\nNo Windows/DATEV live acceptance was performed when this starter was authored.\n\n## One bounded example\n\nConfirm the selected client, period, exclusions and one invoice using existing\nauthorization. A one-invoice trial must explicitly say that the wider population\nis unverified; do not silently replace complete-population checks with sampling.\nRead the full invoice/lines and current mappings before proposing treatment.\nUse the shared procedure, recording only actual DATEV differences and questions\nthat cannot be resolved from the current evidence. Do not assume ECONS state\nlabels, selection controls, VAT rules or journal shape.\n\nWhen native tools work, lead the example directly with those documented host\ntools. Announce each bounded observation window and when it ends. Prefer current\naccessible controls; use screenshots and coordinates only where supported by\nthat host and derived from a fresh view. Refresh state after actions, verify\nclient/document identity and the actual result before the next action. Never\nreuse stale accessibility indices as durable bindings. Save descriptions of\ncontrol roles and actual tool references; rebind to fresh controls on resume.\n\nStart with acquisition and a proposed review. Mapping or posting requires the\noperator's corresponding scope and the host's applicable approval. Before any\nwrite save an `unverified` client entry, then reread current data. Apply all\nmapping, checkbox, client-specific VAT, balanced-journal and posting-verification\nconditions in the shared procedure. If DATEV cannot provide those observations,\npause that write and record the exact gap. The starter has no unattended DATEV\nexecutor or validated replay contract. Manual or host-guided work must keep its\nactual actor/evidence; it cannot generate a clean browser receipt.\n\nWhen native observation/control is absent, unsupported or denied, save that\nexact diagnosis and continue useful permitted work. Guide Francesco through\none ordinary action at a time, using selected local exports or a voluntarily\nsupplied non-login screenshot when available. His descriptions are reported\nevidence, not observations by Vera. A user-supplied screenshot proves only what\nis visible in that supplied image, not a live action or complete population.\nDo not insist on a failed run to request a missing capability. If no real invoice\nevidence is available, deliver the concrete environment/procedure gap report and\nprepared technical request; do not manufacture a populated invoice.\n\n## Save, resume and deliver\n\nAll JSON below is agent-authored internal input. Use one native event after each\nbounded step, including environment checks, denied/unsupported access, manual\nsteps, differences and pauses:\n\n```json\n{\n  \"id\": \"unique-local-step-id\",\n  \"intent\": \"The purpose of this specific step\",\n  \"action\": \"What the host or operator actually did\",\n  \"decision_reason\": \"Known procedure rule or reason for this action\",\n  \"outcome\": \"Actual result, with no unsupported success claim\",\n  \"postcondition\": \"What was checked or still needs checking\",\n  \"source_type\": \"host_tool\",\n  \"source_ref\": \"The actual tool-call reference, operator message or supplied file reference\",\n  \"uncertainties\": [\"A precise unresolved fact when present\"],\n  \"next_step\": \"The exact action from which to resume\"\n}\n```\n\n`source_type` is `host_tool`, `operator_report`, `reference`, or `unknown`.\nUse `reference` for the shipped procedure and attribute its CR-42 basis; never\ncall it newly observed on DATEV. Keep technical event text sanitized. Private\nbusiness values go in the separate client review. The helper reuses the existing\ncheckpoint chain with `capture: null`; its legacy `operator_report` transport\nlabel covers attributed native tool reports as well as operator statements.\nThe explicit source prefix must remain in every summary and CR finding.\nBrowser capture hashes are never synthesized for native actions.\n\n```text\npython <Vera>/scripts/datev_starter.py record <run> --input <event.json> --expected-revision <current>\npython <Vera>/scripts/datev_starter.py resume <run>\npython <Vera>/scripts/datev_starter.py save-review <run> --client-key <local-key> --input <client-snapshot.json> --expected-revision <current-client-revision>\n```\n\nUse `browser-batch-review/v1` only as the existing local report format, following\nbatch-review.md. Create the first client report as soon as a real invoice is\nacquired. Include the exact client scope, all selected invoices and their states,\ndescriptions, proposed and actual treatment, provenance and outstanding checks.\nDo not call operator-reported posting `completed`; use `unverified` until the\nactual protocol and complete same-client non-posted list have been observed.\nKeep incomplete populations paused with `expected_items: null`; for an explicit\none-invoice scope use 1 and state the wider-population limitation. Use the\nexisting `batch_review.py review` command for later human checks and linked\ncorrections. Save before each write and after each invoice, not just at session end.\n\nOn resume call `resume`, read the latest client JSON and reconcile any ambiguous\nexternal action before a retry. Do not repeat completed steps or restart teaching.\nAt completion, interruption or failure return the latest `report_path` and every\nrelevant `client_reviews` link, stating observed/reported/unknown separately.\nA saved checkpoint verifies its history, not professional correctness or replay.\n\n## Prepare the missing adaptation\n\nWhen a real missing capability/binding/adaptation remains, prepare a specific\nsanitized `browser-development-request/v1` with product/version per source,\ncurrent native-host result, the known procedure, exact remaining work and\nacceptance checks. It is a capability request, not a fabricated failure. Use\n`operator_report` for attributed host-tool summaries and `unknown` for untested\noutcomes. Do not upgrade native reports to the browser-only `observed` label.\nNo raw client report, screenshot, login, customer identifier, session URL or\nprivate path belongs in the request. Sanitization is model review, not automatic.\n\n```text\npython <Vera>/scripts/datev_starter.py prepare-request <run> --input <sanitized-request.json> --output <fresh-review-directory>\n```\n\nInspect RICHIESTA.md, request.json and sources.json. Show the exact structured\ntext intended for **https://mparanza.com** and ask for transmission authorization\nif not already explicitly given for that content/destination. Only then call\n`<Vera>/scripts/change_requests.py submit-suggestion --request <review>/request.json`.\nKeep the returned receipt privately beside the frozen review; claim receipt only\nfor an actual `CR-N`. Reuse the same request on retry. No automatic survey,\ninterview or failure report is needed. The text API does not send attachments.\nIf the operator also wants a ZIP, follow development-request.md to export and\nverify it after exact-content approval, and return the ZIP separately. Do not\nmessage Fabio or either Francesco without explicit sending authorization.\n\n## Quali dati arrivano al modello\n\nThe selected host model sees the conversation, product/version and environment\nfacts, authorized native-window accessibility text/screenshots and the selected\ninvoice, full descriptions, account/VAT mappings, amounts, client tax treatment,\njournal and posting evidence that it actually reads. Supplied exports and images\nmay contain these same business details. The model's observations, proposed\ndecisions and report content are also model context. Login remains with the\noperator; stop observation during authentication and do not save credentials.\nDo not retain raw native screenshots/trees in technical checkpoints or developer\npacks. Keep any deliberately retained business evidence in the private case.\n\nThe helper writes local progress and per-client reports; it does not call a\nmodel or server. Local files do not mean offline inference or anonymization.\nPOSIX file modes are not a Windows ACL guarantee; use the operator's private\nauthorized folder. Only the separately reviewed sanitized CR text and routine\nversion/OS/client metadata go to Mparanza after transmission authorization;\nthe ZIP and private client reports are not sent by that API. The ordinary\nmodel-data report can separately send only its digest, random receipt ID, schema\nversion and Vera version to the registered receipt-stamping service. Follow Vera's\nmodel-data-report contract, reporting actual context exposure and unknowns,\nand show its returned readable report even if server stamping is pending.\n"
}