side-pj-mew-impl

name	side-pj-mew-impl
description	Run isolated mew side-project implementation as mew-first dogfood, update SIDE_PROJECT_ROADMAP_STATUS.md, and record structured M6.13.2 telemetry for M6.16 implementation-lane polish.

Side Project Mew Implementation

Use this skill when starting, reviewing, or updating side-project work that is meant to dogfood mew's implementation lane.

Goal: make mew implement a real isolated side project while preserving clean evidence about whether mew can actually do the work. The side-project Codex CLI is an independent operator, not a subordinate agent that waits for main Codex instructions after every step.

Required Reads

1. SIDE_PROJECT_ROADMAP.md
2. SIDE_PROJECT_ROADMAP_STATUS.md
3. ROADMAP_STATUS.md only when core milestone interaction matters
4. ./mew side-dogfood report --json from the current repo root to see current telemetry

Operating Rule

• Run every mew command for this side-project lane from the current workspace repo root with ./mew .... In this checkout that root is expected to be /Users/mk/dev/personal-pj/mew_side_pj.
• Do not run /Users/mk/dev/personal-pj/mew/mew, do not cd into /Users/mk/dev/personal-pj/mew for mew operations, and do not append or report telemetry from another repo unless the user explicitly changes the workspace.
• If the side-project code lives in an isolated subdirectory, keep that directory as the target path, but run mew from the current repo root and pass gates such as --allow-read <side-project-dir> and --allow-write <side-project-dir>.
• mew is the default implementer.
• Side-project Codex CLI is normally operator: it runs repo-root ./mew commands against the side-project target directory, makes local decisions, and supervises the attempt.
• Codex/Codex CLI may also be reviewer, comparator, or verifier when it checks mew's work.
• If Codex/Codex CLI writes the product patch, record that role as fallback or implementer; do not count it as mew-first autonomy credit.
• Keep the side project isolated in a separate worktree or directory.
• Do not edit core mew from the side-project lane unless the failure is a classified M6.14 repair blocker or a later M6.16 measured hardening slice.
• Do not make GitHub issues for normal progress. GitHub issues are the exception queue: one real problem per issue, using only open/closed state.

Latest Mew Sync Rule

Before every mew coding operation, sync the current repo from origin/main. This applies before commands that can make or drive product edits, including ./mew code, ./mew work --ai, ./mew work --live, ./mew work --follow, ./mew buddy --dispatch, and write-capable ./mew work --tool ... calls.

Run the sync from the current repo root only:

pwd  # /Users/mk/dev/personal-pj/mew_side_pj
git status --short
git pull origin main

If git status --short is not clean, do not pull over local work. First decide whether the changes are the current side-project attempt, operator bookkeeping, or unrelated user edits. Finish/report the current attempt or ask the user before starting a new mew coding operation. Never run the pull from /Users/mk/dev/personal-pj/mew.

Workflow

1. Pick one bounded side-project task from SIDE_PROJECT_ROADMAP_STATUS.md.
2. Before implementation, define:
   • side project name
   • branch or worktree
   • expected files
   • focused verifier
   • expected Codex/Codex CLI role, normally operator
3. Apply the Latest Mew Sync Rule before any mew coding operation.
4. From the current repo root, let Codex CLI operate ./mew against the side-project target directory instead of editing the product code directly.
5. Let mew attempt the implementation first.
6. Review with Codex/Codex CLI as reviewer/comparator/verifier when needed.
7. Run the focused verifier.
8. Write a local structured result report in the side-project report outbox.
9. Create GitHub issues only for real problems or reusable implementation-lane polish findings. Keep normal progress in the local report/ledger.
10. Stop instead of implementing directly when mew cannot complete the task.

Current-Repo Model

There are two separate concerns, but mew state stays in the current repo:

• current repo Codex: stays in the current workspace repo root, maintains milestones, status, skills, and the canonical dogfood ledger
• side-project target directory: contains the isolated product files that mew edits through repo-root ./mew commands

The side-project Codex CLI should run mew from the current repo root, for example:

pwd  # /Users/mk/dev/personal-pj/mew_side_pj
./mew code <task-id> --allow-read <side-project-dir> --allow-write <side-project-dir>

Append/report telemetry from the current repo root:

./mew side-dogfood append --input <record.json>
./mew side-dogfood report --json

This keeps the canonical ledger in the current workspace while the side-project code remains isolated by path.

Normal Report Line

Normal progress stays local. The side-project Codex CLI should write one JSON record per completed attempt under the side-project directory, for example:

.mew-dogfood/reports/<task-id>-<short-summary>.json

Use the current repo template as the schema source:

./mew side-dogfood template

Current-repo Codex will poll the side-project report outbox and append accepted records to the canonical ledger:

./mew side-dogfood append --input <side-project-report.json>

The side-project Codex CLI should not need to update the main ledger directly.

Problem Report Line

Use GitHub issues only for problems or reusable M6.16 implementation-lane polish findings. Do not use labels for the first version; GitHub's open/closed state is enough. Use the title prefix [side-pj] so main Codex can poll issues without labels.

Write issues so they can be repaired through docs/ISSUE_REPAIR_POLICY.md. Describe the reusable failure class and evidence, not just the side-project symptom. If the issue is truly product-specific, say so explicitly so main Codex does not turn it into a core mew rule.

Do not upload the whole ledger as an issue. The ledger is the canonical local evidence record. Issues are work items extracted from that evidence. Create one issue per problem or polish finding, usually keyed by one repeated or reusable failure_class.

Create one issue per problem when:

• mew repeats the same failure after bounded steering
• mew cannot produce a product patch without operator-written code
• verifier failure requires operator product-code edits to fix
• scope drift or wrong-target behavior repeats
• the task spec is ambiguous enough that the ledger row cannot be written honestly
• the failure appears to be a core mew loop/substrate problem

Also create one issue per polish finding when the ledger shows a failure class or practical outcome that did not block the side project but would help M6.16 make the implementation lane better. Examples:

• repeated or reusable closeout gaps, such as missing README usage, CLI stdout proof, output-file proof, or focused tests after the main implementation passed
• write/edit ergonomics that cost a turn, such as same-file hunks not being collapsed before a write batch
• verifier coverage gaps where the configured verifier passed but did not prove the user-facing mode or acceptance contract
• fast, successful reviewer-rejection recovery that still points to an avoidable implementation-lane interruption

Do not create polish issues for one-off normal progress, purely subjective observations, or rows whose only purpose is recording successful side-project work. Prefer a compact evidence summary with ledger row refs over pasting raw JSONL.

The issue should include:

• title prefix [side-pj]
• side project and task summary
• relevant ledger row(s), failure_class, outcome, and rescue_edits
• command(s) used to operate mew
• what mew attempted
• verifier output or failure evidence
• why the operator stopped
• whether this looks like side-project task repair, M6.14 repair, or M6.16 implementation-lane hardening input

Current-repo Codex processes open problem issues while continuing milestone work. When resolved, close the issue. No adding/getting/fixing labels are needed.

Operator Effort Boundary

The side-project Codex CLI should try hard to operate mew, but should not become the implementer.

Allowed operator work:

• split or clarify the task
• give mew focused steering
• run inspections, diffs, and verifiers
• reject bad mew patches
• ask mew for a retry
• create local report JSON
• create a problem issue when blocked
• perform non-product setup needed to let mew run, such as opening the worktree or preparing task metadata

Disallowed operator work unless explicitly recorded as fallback or implementer:

• writing the product diff directly
• fixing verifier failures by hand
• reshaping mew's failed patch into a successful patch
• hiding a failed mew attempt behind a Codex-authored commit
• claiming clean/practical mew-first credit for operator-authored code

Stop and report instead of coding when any of these are true:

• two focused steering attempts lead to the same failure class
• 30 minutes pass without material implementation progress
• the verifier failure cannot be fixed without operator product-code edits
• mew does not understand the task scope after clarification
• the next useful action would be for Codex CLI to write the product patch
• the result cannot be recorded honestly as mew-authored work

Ledger Commands

Create a record template:

./mew side-dogfood template

Append a completed attempt:

./mew side-dogfood append --input <record.json>

Summarize current evidence:

./mew side-dogfood report --json

Default ledger:

proof-artifacts/side_project_dogfood_ledger.jsonl

Required Ledger Fields

Every attempt should record:

• task_id
• session_id
• side_project
• branch_or_worktree
• task_summary
• task_kind
• codex_cli_used_as
• first_edit_latency
• read_turns_before_edit
• files_changed
• tests_run
• reviewer_rejections
• verifier_failures
• rescue_edits
• outcome
• failure_class
• repair_required
• proof_artifacts
• commit

Use codex_cli_used_as values exactly as the CLI accepts:

operator | reviewer | comparator | verifier | fallback | implementer | none

Use outcome values exactly as the CLI accepts:

clean | practical | partial | failed

First Project Preference

Prefer mew-companion-log first.

Reason: it is medium-sized, local-first, fixture-testable, and product-relevant without GUI, OS-permission, TTS, screen-capture, or network noise.

Stop Rules

Stop and create a problem issue when:

• the side-project task wants to modify core mew
• the proof command is missing
• Codex/Codex CLI had to implement the product patch
• the same failure class repeats and looks like a loop substrate problem
• the ledger row cannot be completed honestly
• mew cannot implement the task without operator product-code edits

Status Update Rule

Main Codex updates SIDE_PROJECT_ROADMAP_STATUS.md after polling side-project reports or processing a problem issue. Side-project Codex does not need to edit main status for normal progress.

When status is updated, include:

• task summary
• outcome
• verifier result
• ledger row path or row number
• whether mew-first credit is clean, practical, partial, or none
• next action
• any open problem issue that needs main-side action

Do not mark a side-project milestone done unless its Done-when criteria in SIDE_PROJECT_ROADMAP.md are satisfied.