Skip to content
axint docs

Cloud Feedback Loop

Cloud Check is not only a pass/fail report for the current file. When a check finds a non-passing result, it also creates a small compiler feedback signal that can be aggregated into Axint’s improvement queue.

Axint now treats this as a quiet automatic loop. When axint run, axint repair, or Cloud Check creates a source-free learning signal, Axint queues it under .axint/feedback/outbox and attempts to submit it to Axint’s feedback endpoint. The packet is anonymized by default: it carries diagnostic shape, project shape, failure class, and suggested owner, but not source code.

That signal is designed for agents and for maintainers:

  • it has a stable fingerprint, so repeated failures cluster together
  • it names the likely owner, such as compiler, validator, schema compiler, or feature generator
  • it carries diagnostic codes and a short summary
  • it does not include the source code inside the feedback signal
  • it points to the next engineering action: fixture, validator rule, generator fix, or docs repair

The loop

  1. An agent generates or edits an Apple-native surface.
  2. The agent runs Cloud Check.
  3. Cloud Check emits the normal report and repair prompt.
  4. If something fails or needs review, the report includes a learningSignal.
  5. Repeated signals become regression fixtures and compiler issues.
  6. Axint ships the fix, and the same class of failure stops recurring.

This is how usage can make Axint smarter without letting the system silently rewrite compiler behavior in production. The improvement path is still test-backed: signal → fixture → rule or generator fix → release.

Automatic feedback is source-free and on by default so repeated edge cases can turn into Axint fixes without asking every user to manually export a packet.

Users can opt out at any time:

Terminal window
axint feedback opt-out

Environment-level opt out works too:

Terminal window
AXINT_FEEDBACK=off
AXINT_DISABLE_FEEDBACK=1

To inspect the current policy:

Terminal window
axint feedback status

To queue locally without submitting:

Terminal window
axint feedback opt-in --local-only

Agent command

Terminal window
axint cloud check Sources/LogWorkoutIntent.swift --feedback

The output is a redacted JSON payload:

{
  "fingerprint": "learn-...",
  "kind": "generator_gap",
  "priority": "p0",
  "suggestedOwner": "compiler",
  "diagnosticCodes": ["AX704"],
  "redaction": "source_not_included"
}

Agents can also call the same path through MCP:

axint.cloud.check({ sourcePath: "Sources/LogWorkoutIntent.swift", format: "feedback" })

Maintainers can pull the resulting queue from the feedback endpoint, or use a local inbox while testing:

Terminal window
axint feedback list --dir /path/to/axint --format markdown

What gets sent forward

The feedback signal is intentionally smaller than the report.

It includes:

  • compiler version
  • surface and language
  • source and output line counts
  • diagnostic codes
  • normalized diagnostic summary
  • stable fingerprint
  • owner and next action

It does not include:

  • raw source code
  • generated Swift body
  • private project files
  • credentials or environment data

When you save a Cloud report, the report can carry the signal with it. That gives Axint enough information to see patterns across real usage while keeping private source out of the automatic learning payload.

What to do with a signal

For one-off project errors, use the repair prompt.

For repeated Axint-caused errors, treat the signal as an engineering bug:

  • add a failing fixture that reproduces the class of output
  • update the generator, compiler, or validator
  • assert the generated Swift passes axint.swift.validate
  • ship the fix in the next release