n8n node — an authorization checkpoint you can drag

A team with no Python can gate an agent action:

AI Agent  →  [Vavitien]  →  Send Email
                  └ denied →  notify a human

The signing key stays inside your n8n instance. The action, its details and your
policy id go to the service; the key does not.

Status: built, exercised and packaged — not published. It is not on npm, not
on the website, not in LAUNCH_GATES.md, and not mentioned to counsel.
Publishing is a deliberate act — see Before publishing below.

TypeScript with a dist/ build as of 2026-08-20, which is what n8n's registry
expects; the tests run against the COMPILED output, so they guard the artifact
that would actually ship rather than a source that no longer runs.

What is proven, and by what

node    integrations/n8n/test/node_smoke.js          # routing, stubbed service
.venv/bin/python integrations/n8n/test/verify_against_sdk.py   # signature vs the SDK
.venv/bin/python integrations/n8n/test/round_trip.py           # a real server, real HTTP
node    integrations/n8n/test/n8n_contract.js        # n8n's own engine

The last two files are new and each found a real defect on its first run — see
below. Every check in them was verified by mutation: delete the icon, unmask the
private key, reduce the outputs to one, remove a default, and the matching
assertion fails.

round_trip.py starts vavitien.asgi on a loopback port with SQLite backends
and an ordinary policy (an amount ceiling and an audience), registers the
JavaScript agent's public key through the server's own /register_key, and then
drives the node exactly as n8n does. The public key is derived by the JS
signer, not by Python — deriving it on the Python side would have tested
Python's derivation twice and the node's not at all.

Two defects these found

The verify path was wrong for self-hosters. The hosted service exposes
/v1/verify; a self-hosted vavitien.asgi server exposes /verify. The node
had the hosted path hardcoded, so anyone pointing it at their own server — most
of the audience for a no-code block — got a 404 with nothing to explain it. It
is now a credential field with both options.

A description said "resource id". n8n's house style is ID, and their
registry review lints for it.

What is still NOT proven

• A workflow author still cannot obtain a signing key without writing code.
  The credential needs an ed25519 private key ("64 hexadecimal characters") for
  an agent that is already registered. Nothing in the node mints one, and the
  console mints only an in-memory demo agent and never displays the private
  half. So the no-code claim has a code-shaped hole in the middle of it: this
  node removes the days of SDK integration and leaves a five-minute wall a
  non-programmer cannot climb. The console already shows an API key exactly once
  during guided onboarding; agent keys need the same treatment. Close this
  before publishing, or the premise is false.
• Never run inside a live n8n instance. n8n_contract.js uses n8n's real
  Workflow engine and node-types registry, which is a large step past a
  hand-rolled fake, but it is not the same as installing the package into a
  running n8n and dragging the node onto a canvas.
• Never run against the hosted API. The round trip is against a local
  vavitien.asgi server. The beta endpoint is IP-restricted, and no end-to-end
  signed decision through the public endpoint has been demonstrated for any
  client.
• No retry or timeout policy. A slow or flapping service surfaces as a
  workflow error; n8n's own retry settings are the only mitigation today.
• Not tested against n8n version drift. Written to node API version 1.

Deviations from n8n's linter

npm run lint runs eslint-plugin-n8n-nodes-base, the ruleset their registry
review uses, against the TypeScript sources. Two rules are knowingly
unsatisfied, and both are recorded here and in the code rather than suppressed
in config:

cred-class-field-documentation-url-miscased wants documentationUrl
camelCased, and its autofix rewrites the URL into httpsVavitienComDocs. It
directly contradicts cred-class-field-documentation-url-not-http-url, which
demands a URL. The first rule's own description settles which applies: "Only
applicable to nodes in the main repository." It is for nodes inside n8n's
monorepo, where the field is a docs slug. This is a community node published to
npm, so the URL form is correct. Do not run --fix on the credentials file.

node-class-description-outputs-wrong wants a single output. The rule's own
description reads "must be one, or two for If node, or four for Switch node" —
it is keyed to node NAMES, not to capability, and n8n fully supports multi-output
nodes. Two outputs is the entire point here: a denial should route somewhere
useful rather than throw, so the workflow author can send it to a human. Do not
"fix" this.

node-filename-against-convention is now satisfied — it wanted
Vavitien.node.ts, and the source is TypeScript as of 2026-08-20.

Before publishing

1. Convert to TypeScript with a build step — done 2026-08-20. npm run build compiles to dist/ and copies the icon; prepublishOnly runs the
   build and the tests, so a broken package cannot be published by accident.
2. Decide the npm name and take it: n8n-nodes-vavitien. Note the SDK's PyPI
   name was already lost once — vavitien was deleted and cannot be reused.
3. Point documentationUrl at a page that exists. It currently names
   https://vavitien.com/docs, and the site is not hosted yet.
4. Prove one round trip against the hosted API from an allowlisted address.
5. Only then: the website may link to it. A visitor arriving from n8n's registry
   lands on a site whose console screens are marketing mockups — publishing the
   node before that is resolved sends people to the weakest page we have.

Keep it if

• A real prospect says some version of "we run our agents in n8n and cannot
  write Python." One is enough; their tool list becomes the template.
• The first integration shows the gating decision fits in six form fields. If a
  real policy needs more, the block is a toy and the SDK is the product.

Delete it if

• The first three customers all have engineers. Then this serves nobody, and
  every week it stays it accrues maintenance against n8n's release cadence.

The thing that would be worst to get wrong

Someone will assume this checks whether the refund is deserved. In code the
developer knows they are signing a claim; in a drag-and-drop block that intuition
is absent. The node carries a notice field saying so in the UI — Vavitien
checks the action against rules you wrote and records that the check happened; it
cannot tell whether the action is a good idea.

Do not remove that notice to save vertical space. It is the self-attestation
limit, which the claims register requires wherever verification is described,
rendered for an audience that has never read the register.