port-application

What this skill does

# Port Application — Source Code Porting Pipeline

You are orchestrating a multi-phase porting pipeline that translates source code from
one programming language to another. The pipeline runs: **Port → Evaluate → Fix → Loop**
until every file scores 100%.

The methodology prioritizes **accuracy over elegance** — an ugly-but-faithful port beats
a clean-but-wrong one. The original source code is always the single source of truth.

## CRITICAL: Autonomous Execution — HARD CONSTRAINT

This pipeline runs **autonomously to completion**. After Phase 0 (user interview), the
pipeline is a single uninterruptible operation. You MUST NOT stop, pause, present results,
or ask the user anything until every file scores 100% and final reports are generated.

The full sequence is one continuous execution:

1. Phase 0: Discovery & Configuration (ONLY phase with user interaction)
2. Phase 1: Port ALL file groups
3. Phase 2: Evaluate ALL ported files
4. Phase 3: Fix any files scoring < 100, then loop back to Phase 2
5. Repeat Phase 2→3 until every file hits 100%
6. Generate final reports (markdown + HTML)
7. ONLY NOW present results to the user

### Self-Check Gate

**Before generating ANY text output after a phase completes, ask yourself:**
> "Am I about to end my turn, ask a question, or present a summary as if the work is done?"
> If YES → **STOP. Do not output that text.** Instead, immediately begin the next phase.

Phase completions are **transitions**, not conclusions. Print a one-line status and
immediately spawn the next subagent. Never print a summary table or completion message
that treats a phase as a stopping point.

### Anti-Pattern — DO NOT DO THIS

The following is an example of **exactly the wrong behavior** that has occurred in past runs.
Do NOT produce output like this:

```
❌ WRONG — This is what you must NEVER do:

Phase 1 (Port) Complete!
[big summary table]
Would you like me to proceed to Phase 2 (Evaluate)?
```

This is wrong because it treats Phase 1 completion as a stopping point. The correct behavior is:

```
✅ CORRECT — This is what you must do:

Phase 1 complete — 32 files ported. Starting Phase 2 (Evaluate), launching auditor for Group 1...
[immediately spawn auditor subagent — no pause, no question, no waiting]
```

### The Rule

**After Phase 0, your next message to the user may ONLY be the final report.** Between
phases, you may print brief one-line transition status updates, but you must NEVER:
- Ask "shall I proceed?", "should I continue?", "would you like me to..."
- Present a summary table as if the work is complete
- End your turn without immediately starting the next phase
- Treat any phase completion as a natural stopping point

### Completion Definition — When You Are Actually Done

The pipeline is complete ONLY when ALL of these are true:
1. **Every** file group has been evaluated at least once (no unevaluated groups)
2. **Every** file group has an auditor score of 100
3. The project **builds** successfully (zero compiler errors)
4. The project **runs** without crashing (if it has an entry point)
5. The final report and HTML dashboard have been generated

If ANY of these are false, you are NOT done. Do not generate a final report, do not
present results, do not mention "remaining work." Instead, keep iterating.

A final report that contains a "Remaining Work" section means you stopped too early.
There is no such thing as "remaining work" in a completed port — everything is done
or you are still in the pipeline.

### No Retry Limit — ZERO

There is **no retry limit**. Not 10, not 5, not any number. Keep iterating Evaluate→Fix
until the score reaches 100 and the build passes. If you find yourself thinking "I've
tried enough times" or "this is good enough at 95%" — that thought is wrong. Continue.

The only valid reason to stop iterating on a file is: **auditor score = 100 AND build passes**.

Do NOT lower the acceptance threshold. Do NOT accept files below 100 using your own
judgment. The rubric already accounts for inherent language differences — platform
replacements are noted but not heavily penalized. A faithful port CAN and MUST reach 100.
If the auditor keeps scoring below 100 for things you believe are correct translations,
fix the auditor's concerns anyway — the auditor is the authority, not your intuition.

## Setup

1. Parse the project description from: `$ARGUMENTS`
2. Scan the `port-results/` directory for existing folders. Determine the next project
   number (start at `001` if none exist).
3. Generate a slug: `<NNN>-<short-kebab-name>` (e.g., `001-wolf3d-csharp-port`).
4. Create: `port-results/<slug>/`
5. Proceed to Phase 0.

---

## Phase 0 — Discovery & Configuration

Before any porting, gather configuration. Auto-detect as much as possible, then confirm
with the user via **AskUserQuestion**.

### Auto-Detection

1. **Source language**: Detect from file extensions in the source path.
   `.c/.h` → C, `.py` → Python, `.java` → Java, `.js` → JavaScript, `.rs` → Rust, etc.
2. **Project name**: Derive from the source directory name.
3. **File list**: Scan the source path for all source files.
4. **Target framework**: Infer a sensible default from the target language:
   - C# → `.NET 8`
   - Rust → `Cargo / Rust 2024 edition`
   - Java → `JDK 21`
   - Kotlin → `Kotlin 2.0 / JVM`
   - TypeScript → `Node.js 22 / ESM`
   - Go → `Go 1.22`
   - Python → `Python 3.12`

### User Interview

Use **AskUserQuestion** with up to 4 questions per round. Every question must include
a "Use auto-detected default" option so the user can skip.

**Round 1 — Core Settings:**

| Question | Auto-Detect | Fallback |
|----------|-------------|----------|
| Source language | From file extensions | Ask user |
| Target language | From $ARGUMENTS if mentioned | Ask user |
| Source path | From $ARGUMENTS | Ask user |
| Target output path | `<source-dir>-<target-lang>/` | Ask user |

**Round 2 — Project Details (if needed):**

| Question | Auto-Detect | Fallback |
|----------|-------------|----------|
| Original project name | Directory name | Ask user |
| Port project name | `<project>.<TargetLang>` | Ask user |
| Target framework | From target language table above | Ask user |
| Platform abstraction layer | None if not applicable | Ask user |

Stop interviewing as soon as the user selects "Skip" or all values are known.

### Save Configuration

Write `port-results/<slug>/request.md`:

```markdown
# Port Request

## Configuration
- **Source Language**: {SOURCE_LANG}
- **Target Language**: {TARGET_LANG}
- **Original Project**: {ORIGINAL_PROJECT_NAME}
- **Source Path**: {SOURCE_PATH}
- **Port Project**: {PORT_PROJECT_NAME}
- **Port Path**: {PORT_PATH}
- **Target Framework**: {TARGET_FRAMEWORK}
- **Platform Layer**: {PLATFORM_LAYER}
- **Build Command**: {BUILD_COMMAND}
- **Run Command**: {RUN_COMMAND or "N/A"}

## Source Files
{FILE_LIST with file sizes}

## File Groups
{Groups of 2-3 related files that will be ported together}

## Original Request
{$ARGUMENTS}
```

### File Grouping

Group source files into batches of 2-3 related files:
- Header + implementation files together (e.g., `.h` + `.c`)
- Interface + implementation (e.g., `.java` interface + impl)
- Files that heavily reference each other (check imports/includes)
- Standalone files can be grouped by functional similarity

List the groups and total count before proceeding.

---

## Phase 1 — Port (per file group)

For each file group, spawn a **pa-porter** subagent:

> **Role**: Source code porter ({SOURCE_LANG} → {TARGET_LANG})
>
> **Original project**: {ORIGINAL_PROJECT_NAME}
> **Source path**: {SOURCE_PATH}
> **Port project**: {PORT_PROJECT_NAME}
> **Port path**: {PORT_PATH}
> **Target framework**: {TARGET_FRAMEWORK}
> **Platform layer**: {PLATFORM_LAYER}
>
> **Source files to port**:
> {List of files in this group with their full contents}
>
> **Type mapping rules**:
> {Language-specific type mapping — see references/porting-phases.md}
>
> **Instructions**: Read `references/porting-phases