# Future UAT Scenarios

Scenarios tested and deferred, with actual results from 2026-02-05 testing.

---

## Scenario: Multi-Pack Conflict Resolution

**Status:** TESTED - Current behavior documented
**Priority:** Medium
**Trigger:** When enterprises need to combine policies from multiple sources

### User Story
> As a compliance officer, when Pack A (Security Team) says TLS 1.2 and Pack B (Vendor Compliance) says TLS 1.3, I need to see both conflicting policies and understand how to resolve them.

### Test Results (2026-02-05)

**Script:** `uat/scripts/test-multi-pack-conflict.sh`

**Findings:**
- Both packs import successfully
- **Second import OVERWRITES the first** (same subject key in PackSourceStore)
- Both assertions exist in storage (content-addressed = different hashes for different values)
- But policy_source only shows the LAST imported pack

**Example Output:**
```json
{
  "sources": [
    {
      "path": "code://standard/tls/min_version",
      "policy_source": {
        "pack_name": "Compliance-Team",  // <- Only last pack shows
        "pack_version": "0.1.0"
      },
      "value": 1.2
    },
    {
      "path": "code://standard/tls/min_version",
      "policy_source": {
        "pack_name": "Compliance-Team",  // <- Same, even though first was Security-Team
        "pack_version": "0.1.0"
      },
      "value": 1.3
    }
  ]
}
```

**Current Behavior:** Last imported pack wins for policy_source attribution.

### Future Enhancement (if needed)
- [ ] Store multiple pack sources per subject (append, not overwrite)
- [ ] Show all contributing packs in conflict report
- [ ] Add `pack_priority` field to control precedence
- [ ] Support pack composition (extend other packs)

---

## Scenario: Pack Version Update

**Status:** PASS - Working correctly
**Priority:** Medium

### User Story
> As a security lead, when I update our standards pack from v1.0 to v2.0, I need the attribution to update so teams know they're running against current policy.

### Test Results (2026-02-05)

**Script:** `uat/scripts/test-pack-version-update.sh`

**Results:** 6/6 tests passed

| Test | Status |
|------|--------|
| Create v1.0 pack | PASS |
| Import v1.0 | PASS |
| v1.0 attribution shown | PASS |
| Create v2.0 pack | PASS |
| Import v2.0 | PASS |
| v2.0 attribution shown | PASS |
| v1.0 no longer appears | PASS |

**Conclusion:** Pack version updates work correctly. Importing v2.0 supersedes v1.0.

---

## Scenario: Predicate Aliases

**Status:** NOT IMPLEMENTED - Deferred
**Priority:** Low
**Trigger:** Based on enterprise feedback showing predicate naming conflicts

### User Story
> As a security architect, when my policy uses `required=true` but the extractor emits `enabled=true`, I need them to match semantically.

### Implementation Plan (when needed)
1. Add `predicate_aliases` field to Trust Pack schema
2. Update ConceptIndex to check aliases during lookup
3. Consider default aliases: `enabled` ↔ `required` ↔ `mandatory` ↔ `enforced`

---

## Scenario: Pack Signing Key Rotation

**Status:** NOT IMPLEMENTED - Deferred
**Priority:** Low
**Trigger:** Security key management requirements

### User Story
> As a security admin, when our signing key is rotated, I need to re-sign all packs without losing policy content.

### Implementation Plan (when needed)
1. Add `aphoria policy resign` command
2. Preserve pack content hash
3. Update signature with new key
4. Audit log for key rotation

---

## Test Scripts

| Script | Scenario | Status |
|--------|----------|--------|
| `test-enterprise-workflow.sh` | Basic Trust Pack workflow | PASS (12/12) |
| `test-multi-pack-conflict.sh` | Multiple packs, same concept | PASS (7/7) - documents current behavior |
| `test-pack-version-update.sh` | Pack version supersession | PASS (6/6) |

---

## Feedback Collection

Enterprise feedback on these scenarios should be tracked in:
- GitHub Issues with label `enterprise-feedback`
- Internal `#aphoria-enterprise` channel

---

*Last updated: 2026-02-05*
