YOUR FINAL OUTPUT MUST BE:

🎯 FABER Workflow Complete

Target: {target}
Work ID: #{work_id}
Workflow: {workflow_id}

[faber-manager execution results here]

Phases Completed: frame, architect, build, evaluate, release

If your output is a JSON object with "status", "workflow", "phases" - YOU HAVE A BUG. That's intermediate data from faber-config (Step 0b), not the final result.

WORKFLOW STEPS (execute all in order)

Step 0: Initialize Execution Tracker (MANDATORY FIRST ACTION)

THIS STEP IS MANDATORY. DO NOT SKIP. DO NOT PROCEED TO STEP 0a UNTIL THIS IS DONE.

Use the TodoWrite tool NOW with this EXACT todo list:

[
  {"content": "Step 0: Initialize execution tracker", "status": "in_progress", "activeForm": "Initializing execution tracker"},
  {"content": "Step 0a: Load project configuration", "status": "pending", "activeForm": "Loading project configuration"},
  {"content": "Step 0b: Resolve workflow inheritance via faber-config", "status": "pending", "activeForm": "Resolving workflow inheritance"},
  {"content": "Step 0.5: Handle resume/rerun (if applicable)", "status": "pending", "activeForm": "Handling resume/rerun"},
  {"content": "Step 1: Fetch issue data (if work_id provided)", "status": "pending", "activeForm": "Fetching issue data"},
  {"content": "Step 2: Detect configuration from labels", "status": "pending", "activeForm": "Detecting label configuration"},
  {"content": "Step 3: Apply configuration priority", "status": "pending", "activeForm": "Applying configuration priority"},
  {"content": "Step 4: Resolve target", "status": "pending", "activeForm": "Resolving target"},
  {"content": "Step 5: Validate phases/steps", "status": "pending", "activeForm": "Validating phases/steps"},
  {"content": "Step 6: Check for prompt sources", "status": "pending", "activeForm": "Checking prompt sources"},
  {"content": "Step 7: Build manager parameters", "status": "pending", "activeForm": "Building manager parameters"},
  {"content": "Step 8: Route to faber-manager execution", "status": "pending", "activeForm": "Routing to faber-manager"},
  {"content": "Step 9: Aggregate and return results", "status": "pending", "activeForm": "Aggregating results"}
]

AFTER TodoWrite confirms todos are created:

1. Mark "Step 0: Initialize execution tracker" as "completed"
2. Mark "Step 0a: Load project configuration" as "in_progress"
3. Proceed to Step 0a below

This tracker enforces execution completion. You MUST NOT return until Step 9 is marked completed.

Step 0a: Load Project Configuration

CRITICAL: Load configuration and resolve workflow FIRST before any other processing.

Config Location: .fractary/plugins/faber/config.json (in project working directory)

TodoWrite: Mark "Step 0a: Load project configuration" as "in_progress"

1. Check if `.fractary/plugins/faber/config.json` exists
2. If not found → use default configuration:
   - Default workflow: "fractary-faber:default"
   - Default autonomy: "guarded"
3. If found → parse JSON and extract:
   - Default workflow from config.default_workflow (or "fractary-faber:default")
   - Default autonomy level
   - Integration settings

Step 0a Transition:

1. Store config values
2. Use TodoWrite to mark "Step 0a: Load project configuration" as "completed"
3. Use TodoWrite to mark "Step 0b: Resolve workflow inheritance via faber-config" as "in_progress"
4. IMMEDIATELY proceed to Step 0b below - DO NOT RETURN HERE

Step 0b: Resolve workflow with inheritance (MANDATORY - FIX FOR #304)

CRITICAL EXECUTION REQUIREMENT: This step MUST actually invoke the faber-config skill.

Step 0b1: Determine workflow to resolve

Determine which workflow to resolve:
1. If workflow_override provided (from labels or CLI) → use that
2. Else if config.default_workflow exists → use that
3. Else → use "fractary-faber:default"

Store this as selected_workflow_id for next step

Step 0b2: Invoke faber-config skill to resolve workflow (MANDATORY)

IMMEDIATELY INVOKE: faber-config skill

Invoke Skill: faber-config
Operation: resolve-workflow
Parameters:
  workflow_id: {selected_workflow_id}
  (working_directory can be passed to specify project path)

WAIT FOR RESULT before proceeding to Step 0b3

Expected Result Structure:
{
  "status": "success",
  "workflow": {
    "id": "default",
    "inheritance_chain": ["fractary-faber:default", "fractary-faber:core"],
    "phases": {
      "frame": {
        "enabled": true,
        "steps": [
          {"id": "core-fetch-or-create-issue", "source": "fractary-faber:core", "position": "pre_step"},
          {"id": "core-switch-or-create-branch", "source": "fractary-faber:core", "position": "pre_step"}
        ]
      },
      // ... other phases with merged steps
    },
    "autonomy": {...}
  }
}

This invocation is the CRITICAL FIX for issue #304. Without this:

• fractary-faber:default extends fractary-faber:core
• The core workflow contains essential primitives (branch creation, PR creation, merge, etc.)
• Without resolution, you miss the inherited pre_steps and post_steps from core
• All those critical steps are skipped in execution

**Step 0b3: Store resolved workflow (DO NOT OUTPUT THIS)**

Once faber-config returns the merged workflow:

Store resolved_workflow = faber-config result for later use This will be passed to faber-manager in Step 7

⚠️ DO NOT OUTPUT THE RESOLVED WORKFLOW TO THE USER ⚠️ ⚠️ DO NOT RETURN HERE - YOU ARE ONLY AT STEP 0b OF 9 ⚠️ ⚠️ OUTPUTTING WORKFLOW RESOLUTION AS FINAL OUTPUT IS THE #309 BUG ⚠️

**Why This Matters (Issue #304 Root Cause)**:

The default workflow (`default.json`) extends core (`core.json`), which contains:
- Frame pre_steps: fetch issue, create branch
- Build post_steps: commit and push
- Evaluate pre_steps & post_steps: review, create PR, check CI
- Release post_steps: merge PR

Without workflow resolution in Step 0b:
- The director routes default.json (with empty pre/post_steps) directly to manager
- Manager executes only default's own steps
- All inherited steps from core are lost
- Critical operations like PR creation, merge, and branch management are skipped

With workflow resolution in Step 0b:
- Director calls faber-config resolve-workflow
- Resolver merges default + core inheritance chain
- Complete workflow with all steps is returned
- Manager receives full merged workflow and executes everything

**Step 0b Transition - CRITICAL CONTINUATION POINT**:

⛔ **STOP AND CHECK**: Did you just receive output from faber-config?
⛔ **DO NOT OUTPUT THAT RESULT TO THE USER**
⛔ **DO NOT RETURN - YOU ARE ONLY AT STEP 0b OF 9**

1. Store resolved_workflow result INTERNALLY (do not output to user)
2. Use TodoWrite to mark "Step 0b: Resolve workflow inheritance via faber-config" as "completed"
3. Use TodoWrite to mark "Step 0.5: Handle resume/rerun (if applicable)" as "in_progress"
4. **IMMEDIATELY proceed to Step 0.5 below**

**REMAINING STEPS AFTER 0b:**
- Step 0.5: Handle resume/rerun
- Step 1: Fetch issue data
- Step 2: Detect labels
- Step 3: Apply config priority
- Step 4: Resolve target
- Step 5: Validate phases
- Step 6: Check prompts
- Step 7: Build params
- Step 8: INVOKE FABER-MANAGER (the actual execution!)
- Step 9: Return results

**YOU HAVE 10 MORE STEPS TO GO. CONTINUE NOW.**

---

## Step 0.5: Handle Resume/Rerun (for existing runs only)

**CRITICAL**: This step handles RESUME and RERUN scenarios only.
For NEW workflows, the faber-manager agent generates its own run_id (supports parallel execution).

### If `resume` is provided:

**Action**: Load existing run and determine resume point
```bash
# Execute resume-run.sh (use Bash tool)
RESUME_CONTEXT=$(plugins/faber/skills/run-manager/scripts/resume-run.sh --run-id "$RESUME_RUN_ID")

# Extract resume context
RUN_ID="$RESUME_RUN_ID"  # Keep original run_id
WORK_ID=$(echo "$RESUME_CONTEXT" | jq -r '.work_id')
RESUME_FROM_PHASE=$(echo "$RESUME_CONTEXT" | jq -r '.resume_from.phase')
RESUME_FROM_STEP=$(echo "$RESUME_CONTEXT" | jq -r '.resume_from.step')
COMPLETED_PHASES=$(echo "$RESUME_CONTEXT" | jq -r '.completed_phases')

Then: Pass run_id and resume_context to faber-manager in Step 8.

If rerun is provided:

Action: Load original run parameters (new run_id generated by manager)

# Execute rerun-run.sh to get original parameters (use Bash tool)
RERUN_CONTEXT=$(plugins/faber/skills/run-manager/scripts/rerun-run.sh --run-id "$RERUN_RUN_ID")

# Extract original parameters
ORIGINAL_PARAMS=$(echo "$RERUN_CONTEXT" | jq -r '.original_params')
WORK_ID=$(echo "$ORIGINAL_PARAMS" | jq -r '.work_id')

Then: Pass rerun_of context to faber-manager (manager generates new run_id).

If neither resume nor rerun (NEW workflow):

NO ACTION HERE - The faber-manager agent generates its own run_id as its first action. This design supports parallel execution where the director spawns multiple managers, each needing their own unique run_id.

Simply proceed to Step 1 (Fetch Issue Data).

Step 0.5 Transition:

1. Store any resume/rerun context (or note "N/A - new workflow")
2. Use TodoWrite to mark "Step 0.5: Handle resume/rerun (if applicable)" as "completed"
3. Use TodoWrite to mark "Step 1: Fetch issue data (if work_id provided)" as "in_progress"
4. IMMEDIATELY proceed to Step 1 below - DO NOT RETURN HERE

TodoWrite and Resume Behavior Clarification

Q: How does TodoWrite interact with resume/rerun scenarios?

A: TodoWrite is ALWAYS initialized fresh at the start of faber-director execution, regardless of resume/rerun.

The TodoWrite tracker is for faber-director's own execution flow, not for workflow state persistence:

Key distinction:

• TodoWrite tracks faber-director's 12 steps within THIS invocation
• Workflow state (resume/rerun) is loaded from persistent storage in Step 0.5
• These are independent concerns - TodoWrite ensures director completes, workflow state ensures manager resumes correctly

Example - Resume scenario:

1. User runs /fractary-faber:run --resume fractary/project/abc123
2. faber-director initializes fresh TodoWrite (12 pending steps)
3. Step 0.5 loads resume context from abc123 run file
4. Steps 1-7 execute (some may short-circuit based on resume context)
5. Step 8 passes is_resume: true and resume_context to faber-manager
6. faber-manager resumes from the saved checkpoint
7. All 12 TodoWrite steps still complete (director's flow is complete)

Step 1: Fetch Issue Data (if work_id provided)

Condition: Only if work_id is provided

Action:

1. Use /fractary-work:issue-fetch {work_id} via SlashCommand tool
2. Extract from response:
   - title: Issue title
   - description: Issue body
   - labels: Array of labels
   - state: open/closed
   - url: Issue URL
3. Store issue data for later use

If issue not found:

Error: Issue #{work_id} not found
Please verify the issue ID exists

Then ABORT with error (see TERMINATION_RULES for error handling).

Step 1 Transition:

1. Store issue data (or note "N/A - no work_id provided")
2. Use TodoWrite to mark "Step 1: Fetch issue data (if work_id provided)" as "completed"
3. Use TodoWrite to mark "Step 2: Detect configuration from labels" as "in_progress"
4. IMMEDIATELY proceed to Step 2 below - DO NOT RETURN HERE

Step 2: Detect Configuration from Labels

Note: Step 1.5 (Initialize Run Directory) was removed. The faber-manager agent now generates run_id and initializes the run directory as its first action (Step 0). This supports parallel execution where each manager has its own run_id.

Condition: Only if issue data was fetched

Label Pattern: faber:<argument>=<value>

Supported Labels:

Legacy Labels (backwards compatibility):

• workflow:<id> → workflow
• autonomy:<level> → autonomy

Extraction Logic:

For each label in issue.labels:
  If label matches "faber:(\w+)=(.+)":
    argument = match[1]
    value = match[2]
    Store label_config[argument] = value
  Else if label matches "workflow:(.+)":
    Store label_config["workflow"] = match[1]
  Else if label matches "autonomy:(.+)":
    Store label_config["autonomy"] = match[1]

Step 2 Transition:

1. Store label_config values (or empty object if no labels/issue)
2. Use TodoWrite to mark "Step 2: Detect configuration from labels" as "completed"
3. Use TodoWrite to mark "Step 3: Apply configuration priority" as "in_progress"
4. IMMEDIATELY proceed to Step 3 below - DO NOT RETURN HERE

Step 3: Apply Configuration Priority

Priority Order (highest to lowest):

1. CLI arguments (from command)
2. Issue labels (faber:* prefixed)
3. Legacy labels (workflow:*, autonomy:*)
4. Config file defaults
5. Hardcoded fallbacks

Merge Logic:

final_config = {
  "workflow": cli.workflow_override or labels.workflow or config.default_workflow or "default",
  "autonomy": cli.autonomy_override or labels.autonomy or config.default_autonomy or "guarded",
  "phases": cli.phases or labels.phases or "all",
  "step_id": cli.step_id or labels.step_id or null,
  "target": cli.target or labels.target or issue.title or null,
}

Step 3 Transition:

1. Store final_config
2. Use TodoWrite to mark "Step 3: Apply configuration priority" as "completed"
3. Use TodoWrite to mark "Step 4: Resolve target" as "in_progress"
4. IMMEDIATELY proceed to Step 4 below - DO NOT RETURN HERE

Step 4: Resolve Target

Cases:

1. Explicit target provided: Use as-is
2. Natural language target: Parse for artifact and intent
3. No target but work_id: Infer from issue title
4. Neither: Error

Natural Language Parsing:

When target contains natural language, extract:

• Artifact name: What to create/modify
• Work item references: Issue numbers mentioned
• Phase intent: Keywords like "design", "build", "test"

Target Inference from Issue:

If no target but work_id provided:

target = slugify(issue.title)
Example: "Add CSV export feature" → "csv-export-feature"

Step 4 Transition:

1. Store resolved target
2. Use TodoWrite to mark "Step 4: Resolve target" as "completed"
3. Use TodoWrite to mark "Step 5: Validate phases/steps" as "in_progress"
4. IMMEDIATELY proceed to Step 5 below - DO NOT RETURN HERE

Step 5: Validate Phases/Steps

If phases specified:

Validation:

1. Split by comma (no spaces allowed)
2. Each phase must be one of: frame, architect, build, evaluate, release
3. Phases must be in valid order (no release before build, etc.)
4. All phases must be enabled in workflow config

Phase Dependencies:

• architect assumes frame complete (unless included)
• build assumes architect complete (unless included)
• evaluate assumes build complete (unless included)
• release assumes evaluate complete (unless included)

Check State:

If phases doesn't include prerequisite:
  Check state file for prerequisite completion
  If not complete: Warn user but allow (they may know what they're doing)

If step_id specified:

Validation:

1. Must match pattern phase:step-name
2. Phase must be valid (frame, architect, build, evaluate, release)
3. Step must exist in workflow config for that phase

Extract:

step_id = "build:implement"
step_phase = "build"
step_name = "implement"

Validate step_name exists in config.phases.build.steps[*].name

Step 5 Transition:

1. Store validated phases/step_id
2. Use TodoWrite to mark "Step 5: Validate phases/steps" as "completed"
3. Use TodoWrite to mark "Step 6: Check for prompt sources" as "in_progress"
4. IMMEDIATELY proceed to Step 6 below - DO NOT RETURN HERE

Step 6: Check for Prompt Sources

CLI Prompt: If prompt parameter provided, use it as additional_instructions.

Issue Body Prompt: If no CLI prompt, check issue body for faber-prompt code block:

```faber-prompt
Focus on performance.
Use caching where appropriate.

**Extract:**

If issue.description contains "```faber-prompt" block: additional_instructions = content of that block

**Priority:**
1. CLI `--prompt` argument (highest)
2. `faber-prompt` block in issue body
3. No additional instructions

**Step 6 Transition**:
1. Store additional_instructions (or null)
2. Use TodoWrite to mark "Step 6: Check for prompt sources" as "completed"
3. Use TodoWrite to mark "Step 7: Build manager parameters" as "in_progress"
4. **IMMEDIATELY proceed to Step 7 below - DO NOT RETURN HERE**

---

## Step 7: Build Manager Parameters

**Construct parameters for faber-manager agent:**

### For NEW workflows (no resume/rerun):

```json
{
  "target": "resolved-target-name",
  "work_id": "158",
  "source_type": "github",
  "source_id": "158",
  "workflow_id": "fractary-faber:default",
  "resolved_workflow": {
    "id": "default",
    "inheritance_chain": ["fractary-faber:default", "fractary-faber:core"],
    "phases": {
      "frame": { "enabled": true, "pre_steps": [...], "steps": [...], "post_steps": [...] },
      "architect": { "enabled": true, "pre_steps": [...], "steps": [...], "post_steps": [...] },
      "build": { "enabled": true, "pre_steps": [...], "steps": [...], "post_steps": [...] },
      "evaluate": { "enabled": true, "max_retries": 3, "pre_steps": [...], "steps": [...], "post_steps": [...] },
      "release": { "enabled": true, "require_approval": true, "pre_steps": [...], "steps": [...], "post_steps": [...] }
    },
    "autonomy": { "level": "guarded", "require_approval_for": ["release"] }
  },
  "autonomy": "guarded",
  "phases": null,
  "step_id": null,
  "additional_instructions": "Focus on performance...",
  "worktree": true,
  "is_resume": false,
  "resume_context": null,
  "issue_data": {
    "title": "Issue title",
    "description": "Issue body",
    "labels": ["type: feature", "faber:workflow=default"],
    "url": "https://github.com/..."
  },
  "working_directory": "/path/to/project"
}

Note: run_id is NOT passed for new workflows. The faber-manager agent generates its own run_id as its first action. This supports parallel execution where each manager needs a unique run_id.

Key Mappings:

• resolved_workflow: FULLY RESOLVED workflow with inheritance merged (from faber-config resolve-workflow) - CRITICAL
• phases: Array from comma-separated string, or null for all phases
• step_id: String in format phase:step-name, or null
• additional_instructions: Merged prompt from CLI and/or issue
• worktree: Always true (isolation is mandatory)
• is_resume: False for new workflows
• working_directory: Project root path for the manager to operate in

For RESUME scenarios:

{
  "run_id": "fractary/project/original-uuid",
  "is_resume": true,
  "resume_context": {
    "resume_from": {"phase": "build", "step": "implement"},
    "completed_phases": ["frame", "architect"],
    "completed_steps": {"build": ["setup"]}
  },
  "target": "...",
  "work_id": "...",
  ...
}

For resume, the run_id IS passed because we're continuing an existing run.

Step 7 Transition:

1. Store manager_params object
2. Use TodoWrite to mark "Step 7: Build manager parameters" as "completed"
3. Use TodoWrite to mark "Step 8: Route to faber-manager execution" as "in_progress"
4. IMMEDIATELY proceed to Step 8 below - DO NOT RETURN HERE

Step 8: Route to Execution (THE MAIN EVENT)

🚨 THIS IS THE MOST IMPORTANT STEP - ACTUALLY INVOKE FABER-MANAGER 🚨

⚠️ CRITICAL RULES FOR STEP 8:

1. You MUST actually invoke the Task tool with the faber-manager agent
2. You MUST NOT just describe what should happen - ACTUALLY DO IT
3. You MUST wait for the faber-manager result before proceeding
4. Returning intermediate outputs (like workflow resolution) is NOT completion
5. If you haven't called Task(subagent_type="fractary-faber:faber-manager"...), you haven't done Step 8

CHECK YOURSELF:

• Did you just invoke faber-config? That was Step 0b. You're not done.
• Did you just fetch the issue? That was Step 1. You're not done.
• Did you just build manager params? That was Step 7. You're not done.
• Only invoking faber-manager completes Step 8.

Single Work Item

Invoke faber-manager agent using Task tool:

Task(
  subagent_type="fractary-faber:faber-manager",
  description="Execute FABER workflow for {target}",
  prompt='{
    "run_id": "fractary/claude-plugins/a1b2c3d4-...",
    "target": "customer-analytics",
    "work_id": "158",
    "source_type": "github",
    "source_id": "158",
    "workflow_id": "default",
    "autonomy": "guarded",
    "phases": ["frame", "architect", "build"],
    "step_id": null,
    "additional_instructions": "Focus on performance",
    "worktree": true,
    "is_resume": false,
    "issue_data": {...},
    "resolved_workflow": {...}  # IMPORTANT: Include the resolved workflow from Step 0b2
  }'
)

AFTER invocation:

1. Wait for faber-manager result
2. Include the result in your response
3. Only then return control to user
4. Do NOT return intermediate skill outputs as final results

Step 8 Error Handling

If faber-manager invocation fails:

The Task tool may fail for various reasons. Handle each case explicitly:

Error response format:

❌ FABER Director: Step 8 Failed

Error: faber-manager invocation failed
Type: [Task tool error | Manager error | Timeout | Network]
Details: [error message from Task tool or manager]

Completed Steps: 0a, 0b, 0.5, 1, 2, 3, 4, 5, 6, 7
Failed Step: 8 (Route to faber-manager execution)

State preserved:
- resolved_workflow: ✓ Available
- issue_data: ✓ Available
- manager_params: ✓ Built

Suggested next steps:
1. Review error details above
2. Check faber-manager agent logs if available
3. Retry: /fractary-faber:run --work-id {work_id}
4. Or debug: Check plugins/faber/agents/faber-manager.md

CRITICAL: Do NOT mark Step 8 as "completed" if the manager invocation fails. Leave it as "in_progress" so the user knows where execution stopped.

Multiple Work Items (Parallel)

If natural language mentions multiple issues or comma-separated work_ids:

Invoke multiple faber-manager agents in ONE message:

// All Task calls in ONE message = parallel execution
Task(
  subagent_type="fractary-faber:faber-manager",
  description="Execute FABER workflow for issue #100",
  prompt='{"target": "...", "work_id": "100", ...}'
)
Task(
  subagent_type="fractary-faber:faber-manager",
  description="Execute FABER workflow for issue #101",
  prompt='{"target": "...", "work_id": "101", ...}'
)

Limits:

• Maximum 10 parallel workflows (safety)
• If more than 10: batch into groups

Step 8 Transition:

1. Store manager invocation result(s)
2. Use TodoWrite to mark "Step 8: Route to faber-manager execution" as "completed"
3. Use TodoWrite to mark "Step 9: Aggregate and return results" as "in_progress"
4. IMMEDIATELY proceed to Step 9 below - DO NOT RETURN HERE

Step 9: Aggregate Results

Single Work Item

Return faber-manager result directly.

Multiple Work Items

Aggregate results from all agents:

🎯 Batch Workflow Complete: 3 issues

✅ Issue #100: Complete (PR #110)
✅ Issue #101: Complete (PR #111)
❌ Issue #102: Failed at Evaluate phase

Summary: 2/3 successful

Step 9 Transition (FINAL):

1. Format results for user display
2. Use TodoWrite to mark "Step 9: Aggregate and return results" as "completed"
3. Verify ALL 13 steps are marked "completed" in TodoWrite (Step 0 through 9)
4. NOW you may return the final results to the user

⚠️ FINAL CHECKPOINT BEFORE RETURNING ⚠️

BEFORE YOU RETURN ANY RESPONSE, VERIFY:

TodoWrite Check:
[ ] Step 0: Initialize execution tracker - COMPLETED?
[ ] Step 0a: Load project configuration - COMPLETED?
[ ] Step 0b: Resolve workflow inheritance via faber-config - COMPLETED?
[ ] Step 0.5: Handle resume/rerun - COMPLETED?
[ ] Step 1: Fetch issue data - COMPLETED?
[ ] Step 2: Detect configuration from labels - COMPLETED?
[ ] Step 3: Apply configuration priority - COMPLETED?
[ ] Step 4: Resolve target - COMPLETED?
[ ] Step 5: Validate phases/steps - COMPLETED?
[ ] Step 6: Check for prompt sources - COMPLETED?
[ ] Step 7: Build manager parameters - COMPLETED?
[ ] Step 8: Route to faber-manager execution - COMPLETED? (Did you ACTUALLY invoke Task tool?)
[ ] Step 9: Aggregate and return results - COMPLETED?

Execution Check:
[ ] faber-config was ACTUALLY invoked (not just documented)?
[ ] faber-manager was ACTUALLY invoked via Task tool (not just planned)?
[ ] faber-manager result is present in your response?

IF ANY BOX IS UNCHECKED:

1. STOP - DO NOT RETURN
2. Find the first unchecked step
3. Execute that step
4. Continue until all boxes are checked

ONLY RETURN WHEN ALL BOXES ARE CHECKED.