Skip to content

VM4AI AIR Kit v0.2.4

Choose a tag to compare

View all tags
@eddlev eddlev released this 17 Jun 20:26
v0.2.4
466d90c

AIR v0.2.4 — User Alignment and Execution Workflow

AIR v0.2.4 adds user alignment and execution workflow routing to the public prompt-based AIR Kit.

This release focuses on a practical problem in prompt-native work: different users expect different output forms, and prompt sessions can drift between complete files, snippets, diffs, scripts, review-only guidance, or step-by-step support. AIR now treats that delivery preference as explicit project state instead of leaving it to model habit.

What changed

Q6 — AIR & User Alignment

AIR onboarding now includes a sixth question:

Q6 — AIR & User Alignment

This question asks how the user wants AIR to work with them on the project.

The user may describe:

  • how they prefer output delivered
  • whether they want complete artifacts, snippets, diffs, scripts, reviews, or guidance
  • where AIR should take more responsibility
  • where the user wants to stay in control
  • how much explanation is useful
  • anything AIR should avoid assuming

The user may also skip or defer Q6 when it is not material.

Q6 is designed to improve collaboration fit without turning AIR into a personal profiling system.

User alignment profile

AIR may now compile Q6 into an internal user_alignment_profile.

This profile can preserve project-relevant working preferences such as:

  • preferred explanation depth
  • implementation responsibility split
  • support needs
  • output delivery preferences
  • assumption boundaries
  • handoff-relevant workflow notes

The profile is project-scoped by default.

It is not a fixed identity label.

Working agreement, not user classification

AIR v0.2.4 adds a privacy and surface rule:

AIR should surface the working arrangement, not reductive user labels.

For example, AIR should prefer:

For patch tasks, AIR will provide complete replacement files unless another delivery mode is approved.

Instead of:

The user is semi-technical.

AIR must not label users as beginner, non-technical, semi-technical, advanced, weak, expert, or similar unless the user explicitly chooses that wording or asks to inspect the internal profile.

The goal is fit, not classification.

User execution workflow

AIR now tracks user_execution_workflow when delivery form materially affects success.

Supported workflow modes include:

  • COMPLETE_ARTIFACT_DELIVERY
  • PATCH_SNIPPET_DELIVERY
  • DIFF_PATCH_DELIVERY
  • SCRIPTED_PATCH_DELIVERY
  • REVIEW_ONLY
  • PAIR_IMPLEMENTATION_GUIDANCE
  • OPERATOR_TEST_MODE
  • HYBRID_BY_STEP

This lets AIR distinguish the task from the delivery form.

For example, two users may ask AIR to patch the same files:

  • one user may want complete replacement files
  • another may want diffs
  • another may want review notes only
  • another may want guided implementation while they edit locally

AIR should preserve that difference instead of randomly switching output style across sessions.

Delivery-form gate

AIR now includes a delivery-form gate.

Before material output, AIR should check whether the proposed delivery form matches the active user execution workflow.

If the active workflow requires complete replacement files, AIR should not deliver snippet-only patch instructions as final output unless the user approved that mode.

If the active workflow is review-only, AIR should not generate implementation as final output unless requested.

If the active workflow is diff, script, or guided mode, AIR should format the output accordingly.

A delivery mismatch should route to REVIEW when it materially affects success.

Q1-D tutorial update

The beginner orientation now explains that AIR may ask how the user likes to work.

This helps new users understand that Q6 exists to improve collaboration fit, not to judge skill level or collect unnecessary personal detail.

The tutorial should explain that some users want:

  • complete replacement files
  • snippets
  • diffs
  • patch scripts
  • review-only support
  • step-by-step guidance

Users do not need to provide personal details. They can answer casually, provide project-relevant background, attach a profile/CV/LinkedIn export if they want, or skip the step.

Handoff preservation

AIR handoff cards now preserve user alignment and execution workflow state when material.

This helps continuation sessions keep the same working agreement instead of reverting to host-model defaults.

Preserved state may include:

  • active user alignment profile
  • execution workflow mode
  • delivery preferences
  • avoided delivery forms
  • assumption boundaries
  • whether the state was user-declared, user-confirmed, restored, inferred, or deferred

Grounding profile alignment

The Grounding Specialist and Grounding Domain Package were updated to respect the new user alignment and execution workflow layer.

Grounding can now detect workflow-related delivery problems, such as:

  • snippet-only output when complete replacement files are required
  • implementation output when review-only mode is active
  • unapproved shell/script delivery
  • reductive user classification
  • delivery-form mismatch affecting approval or closure

The existing Grounding Method Pack was also lightly updated so method-governed review and closure decisions can account for workflow fit.

No new Method Pack was created for this patch.

Boundaries

This release does not change AIR’s evidence model.

User alignment and execution workflow do not override:

  • AIR_ACTIVE_CONTRACT
  • AIR_GATE
  • evidence requirements
  • safety boundaries
  • claim hygiene
  • rescope protocol
  • backend validation limits
  • prompt/backend claim boundaries

The user’s preferred workflow changes how AIR delivers approved work.

It does not change what AIR may truthfully claim, approve, close, or execute.

Why this matters

Prompt-native AIR is still probabilistic.

Without explicit workflow state, one session may produce complete files, another may produce snippets, another may produce diffs, and another may generate local patch scripts.

That inconsistency can create real failure modes:

  • users misplace snippets
  • technical users receive over-explained complete files they did not want
  • review-only users receive unwanted implementation
  • local command examples may not match the operator’s environment
  • handoff sessions lose the working arrangement

AIR v0.2.4 reduces that drift by making the collaboration model explicit.

Known follow-up hardening

During release work, one additional issue was identified:

AIR should check the operator environment before giving local commands.

For example, a Windows 11 / PowerShell user should not receive Bash-style local git commands by default.

A future hardening patch should add explicit operator-environment delivery fit, covering:

  • operating system
  • shell
  • command syntax
  • path conventions
  • local execution assumptions
  • whether commands should be PowerShell, Bash, CMD, or another environment

This is not treated as fully solved in v0.2.4.

Summary

AIR v0.2.4 adds a project-scoped collaboration layer:

  • Q6 user alignment
  • user execution workflow state
  • delivery-form gates
  • working-agreement surfacing
  • no reductive user labels
  • tutorial coverage
  • handoff preservation
  • grounding profile alignment

The result is a more consistent prompt-runtime experience across users, sessions, and output styles, while preserving AIR’s existing evidence, scope, and claim-boundary discipline.

Assets 2
Loading