{"results":[{"id":"add-host-persists-immediately","text":"`add_host()` persists to the state file immediately (not deferred to context exit).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-autonomous-remediation-system","text":"The AI loop combines resilient observation (shell guards, error suppression, fail-open semantics) with a self-healing contract (observe → condition → action) that supports convergence toward desired state. Together, these mechanisms enable autonomous remediation without requiring human intervention for observed drift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-condition-skip-on-missing-state","text":"AI-loop rule conditions can return `False` when prerequisite state is missing (e.g., IP not yet provisioned), causing the rule to silently skip rather than fail — this handles ordering between dependent rules.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-observe-condition-action-pattern","text":"FTL2 AI-loop rules follow an observe → condition → action pattern: the loop runs `observe` to gather state, calls `condition(state)` to decide whether to act, and calls `action(ftl)` if the condition returns True.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-observe-list-structure","text":"AI-loop observe blocks are lists of dicts with `name`, `module`, `params`, and `host` keys that run commands on target hosts to gather state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-rule-three-phase-contract","text":"FTL2 AI-loop rules follow a three-phase contract: `observe` (gather state), `condition(state)` (check for drift), and `action(ftl)` (remediate) — the reconciliation loop calls these in order automatically.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-rules-fully-trustworthy","text":"AI-loop rules are fully trustworthy for autonomous operation: the three-phase contract ensures predictable behavior, observation resilience prevents false negatives, and cross-rule state sharing enables coordinated multi-rule convergence.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-state-inventory-generated-at-runtime","text":"State and inventory files in ftl2-deployments workspaces are not pre-created — they are generated at runtime by the AI loop.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-typed-function-contract","text":"AI-loop rules define a typed function contract across their three phases: observe is a declarative list of module dicts with name/module/params/host keys, condition receives a structured state dict keyed by observation name, and action receives the full FTL2 runtime with host accessors and module methods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ai-loop-workspace-four-components","text":"Each ftl2-deployments workspace has four key components: `desired_state.txt` (declarative intent), `rules/` (AI loop constraints), `.env` (secrets/config), and runtime-generated state/inventory.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ansible-migration-production-ready","text":"Ansible teams migrating to FTL2 retain familiar patterns while immediately gaining production-grade deployment capabilities: gradual migration preserves CLI, inventory, FQCN, and variable precedence patterns, while state-driven reliability and security-first lifecycle provide enterprise-grade re-runnability and hardening from day one.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ansible-to-ftl2-conversion-mappings","text":"The Ansible-to-FTL2 converter maps: `with_items` to `for` loops, `when` to `if` statements, `handlers` to explicit service restarts, `roles` to function calls, `hosts` to group proxies, `vars` to Python variables.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"auditable-resilient-reexecution","text":"Every re-execution in FTL2 is both safe and auditable: state-driven idempotency prevents resource duplication and enables crash recovery, while event streaming and policy audit trails capture exactly what happened in each run — failed re-runs leave evidence, successful ones prove convergence.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"authorized-key-module-fqcn","text":"SSH public keys are deployed via `ftl.host.ansible.posix.authorized_key()` using the full FQCN pattern, supporting user/key/state parameters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"automation-context-manager-pattern","text":"FTL2 scripts use `async with automation(state_file=..., secret_bindings=...) as ftl:` as the core entry point — this context manager sets up inventory, state, and secrets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"autonomous-error-resilient-operations","text":"AI-loop operations are resilient at every layer: coordinated cross-rule self-healing recovers from drift via observe/condition/action with state-file-mediated communication, while dual error modes (continue-on-error for collection, fail-fast for halt) capture structured errors alongside state persistence for crash recovery.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"autonomous-remediation-verified-convergence","text":"AI-loop autonomous remediation achieves verified convergence: each observe/condition/action cycle uses multi-layer idempotency (shell guards, creates parameter, module-level idempotency) to ensure actions are safe to repeat, and accurate changed/unchanged reporting confirms when desired state has actually been reached, enabling the loop to stop acting.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"autonomous-self-healing-infrastructure-apps","text":"FTL2 enables autonomous self-healing infrastructure applications: durable AI-loop remediation (observe/condition/action with fail-open, persistent state for crash recovery) operates within a full application framework (long-lived daemons, real-time monitoring via htop, event/gate/SSH pipeline).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"azure-state-file-name","text":"The Azure examples use `.ftl2-state-azure.json` as the state file for tracking provisioned resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"backup-and-state-operational-durability","text":"FTL2 achieves operational durability through complementary persistence mechanisms: the state file tracks resource identity and enables crash recovery (control plane), while the backup subsystem preserves file contents before destructive changes (data plane) — together they protect both what exists and what it contains.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null}],"count":97,"limit":20,"offset":0}