v0.4.4

openapi-flow 0.4.4

Changes

• Clarification accepts valid requirements and questions when optional display
  explanations are absent, blank or unusable. Supplied source references and
  functional statements still undergo the original contract checks. The model
  output schema continues to request explanations when enabled; an explanation
  failure does not trigger an extra model call or alter a requirement.
• Tracked literal generation selects original JSON source IDs instead of asking
  the model to reproduce quotations. Code resolves those IDs to original tokens
  and retains typed equality, message ownership and complete input coverage.
  Unquoted strings are checked against the exact proposed string, not a second
  model-written quotation.
• Initial enum interpretation uses explicit not-supplied or OAS-candidate
  decisions, separate from human-answer literal extraction. Code attaches original
  values, message identity and replay fingerprints; a display reason is optional.
• Native configuration receives the complete selected role list, including roles
  with no parameter references. These are business intentions, not inferred output
  contracts, execution edges or permission to use unfinished values.

Packages

• Core
• LangChain
• n8n

Compatibility

Public generation entrypoints remain. Custom model implementations and test
doubles must follow the new tracked-literal JSON candidate protocol and the
initial enum decision schema. The old model-written sourceText output is not
silently converted. Canonical verified source receipts still contain code-owned
original text. Enum selection remains opt-in; no absent input or illustrative
value becomes an approved runtime value merely because an OAS enum exists.

ApiInputEnumAnswerSelection.reason and
WorkflowDraftApiEnumSelection.reason are optional display metadata. Consumers
must handle their absence. NativeNodeConfigurationDescription.selectedRoles
is code-produced context. No dependency versions or n8n execution algorithms
changed in this release.

Verification and limitations

The release record
separates source/package checks, controlled HTTP fixtures, actual-model planning
and isolated engine execution. The release does not claim complete scenario
coverage or that incremental planning is more accurate than single-pass planning.
Versioned strict type/build/Lint/format checks passed. The enabled test suite
passed 1,808/1,809 with only the retained Ajv limitation, no skips/cancellations;
original OAS checks, eleven isolated engine execution conditions and the
independent three-package consumer also passed.

An independent ten-run comparison preserved five original scenarios and their
OAS inputs. It used public 0.4.3 planners with exactly two explicitly injected
candidate functions, not a fully installed 0.4.4 product. Single-pass produced one
JSON, one technical failure and three question waits; incremental produced five
question waits and never reached connection planning. The one generated JSON ran
unchanged in its business logic on isolated n8n 2.37.10: ten local GET requests,
three service aggregates and preserved original response values/types. Deployment
addresses, temporary credentials and the detached Start connection alone were
configured for that local execution. No business service was called.

Question necessity, missing native planning capabilities and broader scenario
quality remain open. The host's discovered full-native-review mode forwarding bug
was fixed locally and is not an OSS feature. Existing user servers and Cloud
deployment are outside this release.

The enabled Ajv properties.__proto__ regression remains a disclosed limitation;
original OAS and request data are not rewritten. The dependency audit still
reports the same five High entries on the upstream n8n SDK/Zod path, with all
other severities zero. This is not a clean-audit or all-tests-pass release.