---
name: architect-rescaffold
description: >
  Drives the rescaffold cycle. Reads the rescaffold trigger queue (from BACKLOG.md or
  RESCAFFOLD-TRIGGERS.md or validate output), determines affected scope, invokes discovery
  for targeted recursive questioning, re-renders only the affected templates, archives the
  prior MATURITY-SCORECARD, runs validate, declares rescaffold complete. Triggered when the
  operator says: "rescaffold", "rescaffold the {layer/concern}", "we changed {sponsor/
  function/scope/regulatory regime/platform}", "validate flagged something we should
  revisit", "kit version bumped, mirror it down", "quarterly review time", "the org just
  added a new skill repo". Also triggered automatically when validate produces blocking
  rescaffold triggers. Refuses to rescaffold scope that has not changed; refuses to skip
  archival of prior scorecard; refuses to ignore unsurfaced honest unknowns from prior
  scaffolds when their resolution conditions have been met.
---

# architect-rescaffold

Drives the rescaffold cycle. Determines affected scope, runs targeted discovery, re-renders affected templates, archives prior state, runs validate, declares rescaffold complete.

The first scaffold (the landing event) is intense. Every rescaffold after is targeted: it touches the surfaces where context shifted, leaves the rest alone, and gets stronger as the deployed instance learns about itself.

## When to invoke

- Operator says: "rescaffold", "rescaffold the {layer/concern}", "we changed {sponsor / function / scope / regulatory regime / platform}", "validate flagged something we should revisit", "kit version bumped, mirror it down", "quarterly review time", "the org just added a new skill repo"
- Validate skill produces a blocking rescaffold trigger (a finding whose scope is layer-level)
- A session log surfaces an honest unknown that is now resolvable
- Calendar cadence (quarterly minimum) per BOOTSTRAP-BRIEF Section XVII rescaffold protocol
- An ADR landed that supersedes prior decisions affecting layer maturity

## Operating procedure

### Step 1: Read the rescaffold trigger queue

Read the rescaffold trigger source. Triggers typically live in:

- `BACKLOG.md` "Rescaffold triggers" section (if maintained as a single inbox)
- `RESCAFFOLD-TRIGGERS.md` (if the deployed instance maintains a dedicated file)
- The most recent validate output (validate emits blocking triggers as part of its scorecard output)
- Recent session logs (operating-mode follow-ups may have appended triggers)

Compile the active trigger list. Each trigger names: what fired, when, which scope is affected (layer-level, relationship-level, skill-level, governance-level), and any preliminary findings already captured.

### Step 2: Determine affected scope

For each trigger, identify which scope is affected:

| Trigger type | Affected scope |
|--------------|---------------|
| L4 mirror sync drift | L4 platform-kit; possibly L5 dossiers if pinned versions changed |
| L7 concern moved to `unknown` | L7 cross-platform glue (the specific concern); possibly affected L5 dossiers |
| Sponsor change | L0 strategy; cascades to L2 philosophy and L3 contract if material |
| Function-mode shift | The relative weight of templates; potentially L4 / L5 if shift is large |
| Regulatory regime activation | L2 philosophy compliance section; L3 telemetry; L7 consent and audit-trail |
| New platform added | L5 (new dossier); L7 (participation declarations); L4 mirror cycle |
| Honest unknown resolved | Specific layer that landed `none` due to the unknown |
| Kit version bump | Mirror the kit's own changes down through the deployed instance's mirrored components |
| Org-local skill repo updated | Recursive skill population revisit |
| Quarterly cadence | Drift detection across all `mature` layers; demote any not operated against in 90+ days |

The scope determination drives Step 3 (which templates to re-render).

### Step 3: Invoke architect-discovery in rescaffold-mode (Mode C)

Invoke `architect-discovery` against the affected scope. Discovery asks targeted questions only:

- For L0 changes: Q1, Q2 + their follow-ups
- For L2 changes: Q3, Q4, Q9 + their follow-ups
- For L3 changes: Q5 + follow-ups
- For L4 changes: Q6 + follow-ups
- For L5 changes: Q7 + follow-ups
- For L7 changes: Q8 + follow-ups
- For governance changes: Q10 + follow-ups
- For function-mode shifts: Q1 (function-mode portion) + cascading template-weight follow-ups

Discovery captures answers in LOCALIZATION-ANSWERS.md as revision-log entries (does not rewrite prior answers).

### Step 4: Re-render affected templates

For each affected layer, re-render the template against the updated answers:

- Render only the affected layer's template; leave others alone
- Preserve all layer artifacts not in the affected scope (their content stays current)
- For L4 with mirror posture: invoke architect-kit-mirror to pull updated source
- For L5 dossiers: per-dossier render; do not bulk-render unless every dossier is affected

### Step 5: Archive the prior MATURITY-SCORECARD

Before running validate, archive the current MATURITY-SCORECARD.md to:

```
{instance_root}/MATURITY-SCORECARD-history/YYYY-MM-DD.md
```

This preserves the scorecard's prior state so the deployed instance can trace its own learning. Naming uses the rescaffold's date.

### Step 6: Run validate

Invoke `skills/validate/SKILL.md` against the deployed instance. Validate produces:

- Updated MATURITY-SCORECARD.md
- New findings (if any)
- New rescaffold triggers (if validate detected anything that requires further rescaffolding)

If validate's new triggers are layer-level: enqueue them for next rescaffold cycle (do not chain rescaffolds without operator approval; cascading rescaffolds without bound is a failure mode).

### Step 7: Update governance artifacts

After validate completes:

- Update OPERATING-MODEL.md "Single highest-leverage next move" with validate's new highest-leverage move
- Update the "Maturity at a glance" table with the new scorecard's per-layer state
- If any L5 dossier changed: update its row in the "Platforms" table
- If any L7 concern changed: update its row in the "Cross-platform glue at a glance" table

### Step 8: Write the rescaffold session log

Per `architect-handoff` skill conventions, write `sessions/YYYY-MM-DD-rescaffold-{purpose}.md`:

- What triggers fired
- Which layers were touched
- Which were skipped (and why)
- What the new scorecard's posture is
- What the next rescaffold trigger queue looks like

The session log is mandatory; rescaffold without a log is the failure mode that erases the kit's ability to trace its own learning.

### Step 9: Declare rescaffold complete

State to the operator (or in the session log if running unattended):

- "Rescaffold complete. Touched: {list of layers}. Skipped: {list with rationale}. New highest-leverage next move: {from scorecard}. Next rescaffold trigger queue: {queue summary or 'empty'}."

If the rescaffold's trigger queue is non-empty after rescaffold (i.e., validate produced new triggers), name them and let the operator decide whether to chain into another rescaffold cycle or defer.

## Refusal conditions

- Refuse to rescaffold scope that has not changed since last scaffold; chasing already-rendered scope is wasted effort
- Refuse to skip the prior-scorecard archival step; without it, the deployed instance cannot trace its own learning
- Refuse to ignore unsurfaced honest unknowns from prior scaffolds when their resolution conditions have been met (per the trigger queue)
- Refuse to chain rescaffold cycles automatically; if validate produces new triggers post-rescaffold, surface to operator and let them decide
- Refuse to rescaffold without writing a session log; the log is what makes learning traceable

## What changes vs. first scaffold

| Aspect | First scaffold | Rescaffold |
|--------|----------------|------------|
| Scope | All eight layers + governance | Only the affected scope |
| Question coverage | Full base set + follow-ups | Targeted base-set subset + follow-ups |
| Runtime | 30 to 90 minutes typical | 10 to 30 minutes typical |
| Templates rendered | All applicable | Only affected |
| Maturity scorecard | New, from scratch | Archived prior; new generated |
| Operator engagement | Sustained | Targeted |
| Outcome | Initial scaffold + trigger queue | Updated scaffold + updated trigger queue |

The kit gets stronger with use because each rescaffold incorporates context that did not exist at the prior scaffold. After many rescaffolds, the deployed instance has a long history of its own learning visible in the scorecard archive.

## Cross-references inside the kit

- `BOOTSTRAP-BRIEF.md` Section XVII (rescaffold protocol)
- `BOOTSTRAP-BRIEF.md` Section V "When you encounter context that may invalidate the current scaffold"
- `decisions/ADR-0005-continuous-rescaffolding.md` - the architecture this skill operationalizes
- `decisions/ADR-0004-recursive-question-discipline.md` - the question discipline rescaffolds inherit
- `skills/architect-discovery/SKILL.md` - invoked in Step 3 in rescaffold-mode (Mode C)
- `skills/validate/SKILL.md` - invoked in Step 6
- `skills/architect-handoff/SKILL.md` - invoked in Step 8 to write the session log
- `skills/architect-kit-mirror/SKILL.md` - invoked when L4 mirror sync triggers fire
- `templates/MATURITY-SCORECARD-template.md` - the scorecard shape both rescaffold and validate produce against
