Lifecycle, download, and repair

Connected System integrations drift over time — vendor APIs change, Business Entities are added, RBAC needs refresh, operators edit online config. Lifecycle commands keep local folders aligned with what is published on the dataplane.

Why it matters

Operators and integrators need a safe loop: pull truth from the dataplane, repair local files, re-validate, re-test, and confirm online state — without hand-editing generated deploy manifests.

The Operate phase is ongoing maintenance after initial certification. It is not where you design Role Assistants — see Role Assistants for Role Assistant concepts.

Prerequisites

Existing published systemKey
aifabrix auth status green for online commands
Local git backup before download or delete

Where it lives

Command	Effect
`download`	Overwrites local folder with online truth
`show --online`	Read-only online snapshot
`repair`	Fixes application.yaml lists, metadataSchema drift
`delete`	Destructive online removal

Manifest section: system.lifecycle. UI: Connected System Audit & History (lifecycle / audit tab).

Builder MCP


Manifest section	`system.lifecycle`
UI tab	Audit & History
Help topics	`workflow`, `connectedSystemUi`
Repair hooks	full `repair` graph after download

Same commands documented for the Operate band: Download, repair, and show online.

How to set

Compare before mutating local files:

aifabrix show <systemKey> --online

Pull online config when intentional:

aifabrix download <systemKey>

Repair drift after download or hand edits:

aifabrix repair <systemKey> --dry-run
aifabrix repair <systemKey> --rbac --expose
aifabrix validate <systemKey>

Re-test and re-upload when ready:

aifabrix test-integration <systemKey>
aifabrix test-e2e <systemKey>
aifabrix upload <systemKey> --probe
aifabrix upload <systemKey>

Re-certify when material change:

aifabrix verify-operations <systemKey>
aifabrix verify-trust <systemKey>
aifabrix verify-governance <systemKey> --subject-email scoped-user@example.com
aifabrix lifecycle <systemKey>

Optional cert sync when online state changed:

aifabrix validate <systemKey> --cert-sync

Defaults and examples

Recommended maintenance loop:

show --online → download (if needed) → repair --dry-run → repair
  → validate → test-e2e → upload → verify-operations
  → verify-trust → verify-governance → lifecycle

Trigger	Action
Vendor API version bump	download/repair, E2E, re-certify ops
New datasource added locally	repair, validate, upload, full cert ladder
Governance policy change	verify-governance with scoped test user
Operator edited online config	download, diff, repair

Example identity fields repair syncs on datasources:

{
  "key": "example-customers",
  "displayName": "Customers",
  "systemKey": "example-crm",
  "entityType": "recordStorage",
  "resourceType": "customer",
  "primaryKey": ["externalId"]
}

Validate

aifabrix show <systemKey> --online
aifabrix validate <systemKey>

Log manual integration edits outside repair in your team's integration changelog when your process requires audit of hand-patched JSON.

Common mistakes

Mistake	Impact	Fix
Hand-edit deploy JSON	Overwritten on next `json`	Use repair + validate
Download without repair	Merge conflicts in YAML lists	`--dry-run` first
Re-upload without E2E	Regressions in production	test-e2e before cert
Only verify-trust on refresh	Ops/governance stale	Full pillar ladder

Limits

delete is destructive — confirm environment and backups before use. download overwrites local work — commit or stash before pulling online truth.

Lifecycle commands do not rotate vendor secrets — update kv:// paths and re-upload after credential rotation (Configure authentication).

repair cannot invent missing business metadata — it aligns lists and schema bands; field mapping design still happens in Business Entities configure pages.

After download, run repair --dry-run before committing — online edits may include operator experiments you should not blindly merge into mainline git.

Schedule full pillar re-runs after vendor major version upgrades even when validate stays green — silent API behavior changes often surface first in test-e2e, not schema validators.

delete followed by re-upload is not a substitute for repair when only RBAC lists drifted — prefer repair-first workflows to preserve stable systemKey history in operator audit logs.

Compare show --online output before and after vendor maintenance windows — scheduled vendor outages mimic integration regressions until test-integration confirms credential validity.

Documentation Index