Canonizing Flaws

Purpose

Interview the user about an emergent behavior that has become beloved or expected, and register it in the Canon of Flaws for protection against "optimization."

Philosophy

> "Beloved 'bugs' are registered and protected from optimization"

The key insight is that a "perfect" implementation of the original design would often be worse than the imperfect reality users have come to love. This skill protects the emergent soul of products.

Pre-Flight Checks

1. **Sigil Setup**: Verify `.sigil-setup-complete` exists in the project root

2. **Canon File**: Check that `sigil-mark/soul-binder/canon-of-flaws.yaml` exists

- If missing, create it with an empty flaws array structure

3. **Strictness Level**: Load the current strictness setting from `.sigilrc.yaml`

Workflow

Step 1: Identify the Behavior

If `behavior_name` is not provided by the user, use AskUserQuestion to prompt:

**Question**: "What emergent behavior would you like to protect?"

Explain what qualifies as a canonizable flaw:

Examples include:

Step 2: Interview - Intended vs Emergent Behavior

Gather the context of what was intended versus what emerged.

**Question 2.1: Intended Behavior**

"What was the INTENDED behavior? What should have happened according to the original design?"

**Question 2.2: Emergent Behavior**

"What ACTUALLY happens (that became beloved)? Describe the behavior users have come to expect."

**Question 2.3: Discovery**

"How did you discover this behavior was valued?"

Options:

Step 3: Interview - Protection Criteria

Assess whether the behavior meets the threshold for protection.

**Question 3.1: Usage**

"Approximately what percentage of users rely on this behavior?"

Options:

If usage is < 5%, warn the user but allow proceeding with UNDER_REVIEW status.

**Question 3.2: Community Attachment**

"How would users react if this behavior was 'fixed'?"

Options:

**Question 3.3: Skill Expression (Optional)**

"Does this behavior reward skill or expertise?"

Options:

Step 4: Define Protection

**Question 4.1: Affected Code**

"What code patterns might accidentally 'fix' this behavior?"

Provide examples of glob patterns:

Accept glob patterns that should trigger protection checks in code review.

**Question 4.2: Protection Rule**

"Complete this sentence: 'Any change that __________ must be BLOCKED.'"

Example: "Any change that prevents the double-click animation must be BLOCKED."

Step 5: Generate Entry

Read the existing `canon-of-flaws.yaml` file to determine the next sequential flaw ID. Generate a YAML entry in this format:

```yaml

name: "{behavior_name}"

status: "PROTECTED" # or UNDER_REVIEW if < 5% usage

canonized_date: "{today's date}"

canonized_by: "{user name or 'Taste Owner'}"

description: |

{Brief description of the flaw}

intended_behavior: |

{Response from Question 2.1}

emergent_behavior: |

{Response from Question 2.2}

why_protected: |

- Discovery: {Response from Question 2.3}

- Usage: {Response from Question 3.1}

- Attachment: {Response from Question 3.2}

- {Additional context if provided}

affected_code_patterns:

- "{pattern_1}"

- "{pattern_2}"

protection_rule: |

{Response from Question 4.2}

de_canonization:

requires_threshold: 70 # percent approval required

cooldown_days: 180

```

Step 6: Confirm and Save

Display the generated entry to the user in a formatted, readable way:

"Here's the Canon of Flaws entry I've prepared:

{formatted_entry}

Does this accurately capture the behavior to protect?"

Options:

On confirmation:

1. Load the existing `canon-of-flaws.yaml` file

2. Append the new flaw entry to the flaws array

3. Update the `last_updated` timestamp in the file

4. Save the file with the new entry

Step 7: Report

Provide a summary report to the user:

```

{status_emoji} FLAW-{id} "{name}" has been added to the Canon of Flaws.

Status: {PROTECTED | UNDER_REVIEW}

The agent will now {BLOCK | WARN on} any change that matches:

{affected_patterns}

Protection Rule:

"{protection_rule}"

De-canonization process:

- Requires 70% community approval via /consult

- Requires Taste Owner sign-off via /approve

- Update canon-of-flaws.yaml status to DE_CANONIZED

Next steps:

- /craft will respect this flaw during implementation

- Changes to affected patterns will be {blocked | flagged}

```

Strictness Behavior

The skill's behavior varies based on the strictness level defined in `.sigilrc.yaml`:

| Strictness | Protected Flaw Violation |

|------------|--------------------------|

| discovery | "Consider" - informational only |

| guiding | Warning with explanation |

| enforcing | BLOCK with override option |

| strict | BLOCK with override option |

Error Handling

| Error | Cause | Resolution |

|-------|-------|------------|

| "Setup not complete" | Missing `.sigil-setup-complete` marker | Run `/setup` first |

| "Usage below threshold" | < 5% usage reported | Allow with UNDER_REVIEW status |

| "Similar flaw exists" | Duplicate pattern detected | Suggest updating existing flaw entry |

| "Canon file missing" | No `canon-of-flaws.yaml` found | Create empty file with proper structure |

Constraints

**Do NOT:**

**DO:**