Make the feature guardian conversational and remediation-capable

[khaliqgant]

Problem

Factory's feature guardian now has a durable, idempotent scheduled question cycle, but the interaction ends after the question is delivered. Reactions and threaded answers are not yet turned into a full verification conversation, durable confirmation evidence, or a remediation issue.

The desired loop is: ask -> discuss -> safely verify -> record confirmation, or open a concrete factory-ready issue when the feature is broken, drifted, or cannot be confirmed.

Goal

Adopt the reusable conversational feature-guardian extension proposed for Relay/Workforce and make Factory's guardian own each response through a terminal, auditable outcome.

Related reference/adoption issue: AgentWorkforce/relay#1347.

Factory should extend shared plumbing in the same way repository reviewers extend Workforce's defineReviewAgent / defineReviewPersona: Factory supplies its manifest, named procedures, tier prerequisites, prompt, and issue policy; shared code supplies event correlation, state transitions, idempotency, delivery, confirmation records, and remediation writeback.

Factory behavior

1. Keep the existing hourly criticality/tier-ordered question cycle and provider-confirmed Slack delivery.
2. Listen only to reactions and replies attached to the exact guardian message in the configured channel.
3. Continue a turn-by-turn thread when the response is ambiguous, untested, or reports a problem. Ask targeted questions grounded in the manifest feature's CLI/API/config surface, source locations, named procedure, and verification tier.
4. When safe prerequisites are available, run the exact procedure from .agentworkforce/features/verify/procedures.md in an isolated workspace and report positive/negative assertions and cleanup evidence.
5. Preserve SKIP and MANUAL for unavailable provider, fleet, cloud, or live-work tiers. Absence of prerequisites must not become confirmation.
6. On confirmation, append one immutable record tied to the feature ID and manifest revision, including actor/verifier, timestamp, commands and test counts where applicable, result, and Slack thread identity.
7. On an established implementation, test, catalog, or runbook defect, open or update one deduplicated issue in AgentWorkforce/factory with factory-ready, complete reproduction/evidence, affected feature/procedure paths, acceptance criteria, and a Slack backlink.
8. Reply in Slack with the confirmation summary or remediation issue link, then checkpoint the terminal state under exact-revision CAS.

Integration requirements

• Reuse the shared feature-guardian factory rather than duplicating Relay's event parsing/state machine.
• Define explicit Factory adapters for manifest loading, procedure lookup/execution, confirmation authority, tier gating, issue classification/body, and repository routing.
• Preserve the existing fail-closed state rules, bounded records, safe manifest reconciliation, stable idempotency keys, provider receipt validation, and post-then-checkpoint retry behavior.
• Correlate duplicate/out-of-order Slack events safely and prevent a reply from confirming the wrong feature or generation.
• Give the persona only the scoped Slack conversation read/write and Factory GitHub issue-write capabilities required for this loop.

Acceptance criteria

• Checkmark/affirmative, wrench/failure, untested, ambiguous, and threaded text responses have explicit tested transitions.
• The guardian supports at least two clarification turns and resumes correctly after restart.
• Confirmation is stored once with feature ID, manifest revision, generation, evidence, actor/verifier, timestamp, and Slack thread identity.
• Factory procedures run with their documented prerequisites, isolated setup, assertions, reporting, and cleanup.
• Tier 3-6 checks remain gated and are reported as SKIP/MANUAL when prerequisites or opt-in are absent.
• A proven defect creates exactly one factory-ready Factory issue and retries never duplicate it.
• The issue distinguishes implementation, test, manifest, procedure, and documentation drift and contains an agent-executable definition of done.
• Slack receives the final confirmation or issue link only after the corresponding durable/provider write is confirmed.
• Tests cover duplicate and delayed events, CAS conflict, retry after post-before-checkpoint, malformed state, manifest changes, issue-write failures, and unauthorized channel/repository input.
• Existing guardian schedule, ordering, cycle reset, and error-notification behavior remain green.

Out of scope

• Treating message delivery as feature confirmation.
• Running credentialed/destructive checks without explicit authorization.
• Automatically implementing or merging the generated remediation issue.