170: Make the feature guardian conversational and remediation-capable

[agent-relay-code]

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.

Fixes #170

---

Summary by cubic

Makes Factory’s feature guardian conversational and remediation-capable. Turns Slack replies into a guided verification that records immutable confirmations or opens one deduplicated factory-ready issue with evidence; also ships a reusable API and hardens remediation to wait for GitHub receipts and avoid duplicates on retries/merges.

• New Features

  • Converts reactions and replies on the exact guardian message into a guided thread with up to two clarification turns and correct resume after restart.
  • Runs named procedures from .agentworkforce/features/verify/procedures.md in an isolated workspace; honors tier gates and reports SKIP/MANUAL when prerequisites are missing.
  • Writes one immutable confirmation per feature/revision with actor/verifier, timestamp, commands and test counts, and Slack thread identity.
  • Opens/updates exactly one Factory remediation issue with factory-ready, defect kind, reproduction/evidence, acceptance criteria, and a Slack backlink; waits for GitHub writeback receipts and dedupes across retries/merges via a remediation marker. Confirms Slack output only after durable provider receipts with exact-revision state, idempotency keys, and event correlation.

• Refactors

  • Introduces a shared guardian engine at @agent-relay/factory/feature-guardian and adopts it in the Factory agent via explicit adapters (manifest, procedures, tier gating, issue policy, routing).
  • Publishes ./feature-guardian subpath exporting defineFeatureGuardianAgent and runGuardianConversationTurn; adds the api-feature-guardian manifest feature and verifies dist/E2E subpath imports.
  • Updates persona scopes and memory (repo read broadened, Factory issue write allowed, Slack scopes limited to needed conversation read/write).
  • Adds comprehensive tests for duplicate/delayed Slack events, CAS conflicts, retry after post-then-checkpoint, malformed state, issue-write failures, unauthorized input, and remediation loop durability.

^{Written for commit 4f0f515. Summary will update on new commits.}

[agent-relay-code]

Verdict: Clean. Preserves Path 12's fail-closed cycle — durable question registration precedes the progress checkpoint, confirmations/remediations are CAS-fenced with provider-confirmed receipts and append-only transition guards, and the new conversational surface plus the allowlist↔procedures.md equivalence are represented in the manifest and bound by tests.

_{maintainability review · .agentworkforce/workforce/personas/maintainability.md}

[kjgbot]

Babysitter handoff: this PR is reconciled with current main, mergeable, and green on fresh head 4f0f515. I hardened exact Slack/provider correlation, restart-safe revision and tier gating, immutable confirmation evidence, isolated exact-procedure execution/cleanup, and deduplicated remediation retries; the main safety trade-off is deliberately reporting live fleet/cloud tiers as SKIP/MANUAL unless the required opt-in and verifiable cleanup scope exist. I’m happy to walk a human reviewer through the state-machine or tier-gating decisions before approval. No merge was performed.