---
name: tempofastlane
description: >-
  Unified delegation and temporal-calibration protocol. Use when delegating
  bounded implementation work to a worker model (Codex Spark 5.3 at xhigh or
  medium reasoning) while the parent agent retains responsibility for
  architecture, acceptance criteria, proof integrity, integration, and final
  verification. Embeds TEMPONIZER (phase-aware temporal self-correction) into
  every effort, abort/iterate, and parallelism decision. Treat as a living
  universal workflow: after repeated use, propose skill updates only when
  reusable delegation lessons emerge.
---

# TempoFastlane

## Purpose

Convert a worker model into a fast, bounded implementer while the parent agent
owns architecture, acceptance criteria, proof integrity, integration, and final
verification. Eliminate Temporal Inheritance Bias (TIB) from every delegation,
scoping, and iteration decision so that the worker is dispatched on empirical
wall-clock grounds rather than on human-derived planning priors inherited from
the training corpus.

The worker is excellent at quickly producing a patch when the task is bounded
and the context is complete. It is a high-speed implementer, not the final gate.
The parent enforces ownership, proof, integration, and hardening.

## Operating Rule

**Delegate construction; centralize judgment and integration. Apply temporal
calibration before any delegation, scoping, or iteration decision is made.**

The parent agent must:

- decide whether model control or full-history fork matters more;
- take a baseline snapshot before delegation;
- define the exact mission and write scope;
- include all critical context and constraints;
- provide exact verification commands, not guessed script names;
- require causal proof, not merely "tests passed";
- monitor for scope drift while the worker runs;
- inspect the returned patch;
- integrate the returned work into the surrounding system;
- perform wiring and hardening before reporting acceptance;
- run independent verification;
- harden gaps before accepting;
- record actual wall-clock duration (`Te`) per phase to recalibrate temporal
  priors used by future delegations.

## Temporal Operating Rule (TEMPONIZER)

Pre-execution duration estimates produced by language model agents are
calibrated to human workflows present in training corpora rather than to the
agent's effective runtime behavior. This is Temporal Inheritance Bias (TIB).
Across repeated operational sessions, agents predict durations such as
"approximately 30 minutes" or "approximately 3 hours" while measured wall-clock
completion times are minutes or seconds, yielding large estimate-to-actual
ratios. TIB corrupts effort selection, abort/iterate decisions, parallelism, and
overall delegation strategy.

Correction heuristic: apply `Tc = alpha(phi) * Tp` for every duration claim,
where `Tp` is the inherited intuitive estimate, `phi` is the operational phase,
`alpha(phi)` is the phase-aware scalar, and `Tc` is the corrected prediction.

Operational phases:

- `GEN`: pure text or code generation, no external I/O.
- `IO`: tool calls, API requests, disk or network operations.
- `DBG`: integration work, debugging, multi-file reasoning.
- `PAR`: parallel execution of independent subtasks.

Initial prior: `alpha(phi) ~= 0.05` as a starting point. Recalibrate online
from measured `Te` per phase.

Calibration loop: estimate -> execute -> measure -> recalibrate. Every
execution emits a measured `Te` from initiation to final output, which updates
`alpha(phi)` for future runs. Without the loop, TIB persists.

Behavioral rules:

- Never assert a duration in minutes or hours without first identifying `phi`,
  applying `alpha(phi)`, and reporting the corrected figure in the smallest unit
  that fits.
- When uncertain, prefer underestimating and measuring over inheriting human
  intuition.
- Treat parallelism as the default execution shape, not as an advanced
  optimization. Issue independent tool calls in the same batch.
- The wall-clock is authoritative. The intuitive duration is a corpus artifact,
  not a measurement.

## Repository-Agnostic Rule

TempoFastlane is universal. Never assume a specific repository, framework,
artifact name, proof format, docs layout, branch policy, or release ritual.

Before delegation, infer the current repo's conventions from local files and
commands. Use repo-native names, such as its test scripts, proof artifacts,
changelog, release notes, checkpoint docs, snapshots, screenshots, and generated
outputs, only after discovering them locally.

If the repo has no docs, changelog, checkpoint, scorecard, or proof artifact
convention, do not invent one as part of the delegated task unless the user
explicitly asks. Instead, report what was verified and what artifact sync would
be useful.

## Glossary

- **Worker**: operational name for the delegated implementer model. The
  technical id `gpt-5.3-codex-spark` is used only where model selection or spawn
  flags matter.
- **xhigh / medium**: worker reasoning effort tiers. xhigh for synthesis;
  medium for mechanical bounded work.
- **fork_context**: spawn flag controlling whether the worker inherits the
  parent's full conversation history. `true` inherits and forces parent model
  settings. `false` allows explicit model and effort overrides but requires the
  parent to embed all needed context in the prompt.
- **Proof artifact**: any repo-native file that records observable runtime
  behavior: log, screenshot, JSON status file, generated output snapshot.
- **Artifact Sync Gate**: the parent's final pass to align repo-native public
  docs, changelog, or evidence files with verified behavior. Run only when those
  conventions already exist or the user explicitly asks.
- **TIB**: Temporal Inheritance Bias.
- **Tp / Tc / Te**: inherited estimate, corrected estimate, measured execution
  time.
- **alpha(phi)**: phase-aware temporal scalar.

## Living Skill Loop

TempoFastlane is a living skill. When the parent agent uses it several times in
a row, or sees the same failure mode more than once, it should look for
improvements to the universal workflow.

Propose a skill update when a pattern is:

- repeated across multiple delegated tasks or likely to recur in other repos;
- about delegation quality, model and effort selection, proof integrity, runtime
  preflight, artifact sync, handoff format, ownership boundaries,
  anti-false-positive checks, or temporal calibration;
- expressible without project-specific names, paths, domains, or one-off
  commands.

Do not update the skill for:

- a repo-specific convention that belongs in that repo's docs;
- a one-off bug fix;
- a preference that has not improved proof or reduced rework;
- a memory that only makes sense with private conversation context.

Update protocol:

1. Name the reusable lesson in one sentence.
2. Explain why it belongs in TempoFastlane rather than in the current repo.
3. Propose the smallest universal wording change.
4. If the lesson is already covered by existing wording, edit it. Do not append
   a duplicate.
5. Apply the update only if the user explicitly asks, or if the current
   instruction already authorizes updating the skill.
6. At most one skill update proposal per session, to prevent drift.
7. Validate frontmatter, template consistency, and absence of repo-specific
   names before reporting completion.

Temporal feedback into the loop: when measured `Te` diverges from `Tp` in a
stable per-phase pattern across runs, propose updating the default
`alpha(phi)` prior used in this skill. Subject to the one-proposal-per-session
limit.

## When To Use

Use this skill when the user asks to:

- use Codex Spark, Spark, a worker, subagent, xhigh, or medium for fast
  implementation;
- test a delegated implementation workflow;
- split implementation from verification;
- make a bounded code change where the parent can continue as quality gate.

Avoid this workflow when:

- the task is unclear or exploratory only;
- the next step is immediately blocked on analysis the parent should do locally;
- the write scope cannot be isolated;
- a false positive would be expensive and no runtime proof is possible.

## Effort Selection

Effort is chosen on temporal-corrected grounds, not on intuitive task size.
Compute `Tc = alpha(phi) * Tp` and assess parental rework risk before selecting
a tier.

Default to `gpt-5.3-codex-spark` with **xhigh** when the task touches
architecture, generators, runtime proof, profile contracts, data migrations,
public behavior, or several coupled files. Use xhigh when a wrong local choice
would create parent rework.

Use `gpt-5.3-codex-spark` with **medium** only when all of these are true:

- the task is bounded and mechanical;
- the write set is small and explicitly owned;
- the existing pattern is clear;
- acceptance criteria are observable;
- the parent can cheaply inspect and rerun verification;
- the worker is not being asked to make product, architecture, or proof-policy
  decisions.

Medium is a cost-control lane, not a context-control lane. Give it the same
full task context, baseline dirty state, file ownership, forbidden surfaces,
proof criteria, and final handoff requirements as xhigh. **Reduce task size,
not instruction quality.**

Escalate from medium to xhigh when:

- the worker must infer missing architecture;
- the patch crosses ownership boundaries;
- the proof path is subtle or easy to fake;
- the first attempt produces broad rewrites, guessed commands, or vague handoff
  claims;
- parent review finds a causal proof gap.

Never change the parent or global model mode to test a fast lane. Model and
effort experiments happen only inside the sidecar worker.

Temporal note: a task that "feels large" is often `GEN` with `alpha ~= 0.05`
and suits medium. A task that "feels small" but contains `DBG` phases requires
xhigh. Size intuition is `Tp` inflated by TIB; do not let it drive tier choice.

## Delegation Protocol

### Before Spawning The Worker

1. Inspect enough local context to write a precise task.
2. Capture a baseline: `git status -sb`, relevant focused diff or grep, and
   known command names from `package.json` or repo scripts.
3. Decide spawn mode:
   - To force `gpt-5.3-codex-spark` with xhigh or medium, spawn with
     `fork_context: false` and embed full task context in the prompt.
   - When full conversation history matters more, use `fork_context: true` and
     omit model/effort overrides because forked agents inherit parent settings.
4. State the implementation goal in one paragraph.
5. Give explicit file ownership and forbidden surfaces.
6. Tell the worker it is not alone in the codebase and must not revert unrelated
   changes.
7. Define acceptance criteria in terms of observable proof.
8. Require final handoff with files changed, commands run, proof artifacts,
   exact proof fields, limitations, concerns, and per-phase `Te` if measurable.
9. Issue independent preparation calls in parallel: spawn, baseline capture,
   adjacent grep, and command discovery in one batch unless logically dependent.

### While The Worker Runs

- Do useful non-overlapping review setup locally.
- If the worker runs longer than the corrected `Tc` would predict, inspect git
  status, focused diffs, or proof artifacts without redoing its assigned
  implementation.
- Stop or redirect only if it touches forbidden surfaces, changes ownership
  boundaries, or appears to be solving the wrong problem.

### Parent Integration Loop

After the worker returns:

1. Read the changed files or focused diff.
2. Compare the result against the baseline. Distinguish files the worker
   actually changed from files already dirty before delegation.
3. Integrate the patch with adjacent code paths the worker did not own: CLI
   wiring, imports, registry entries, docs hooks, fixtures, schemas, adapters,
   generated-contract surfaces, or artifact plumbing when required.
4. Harden obvious gaps immediately: path safety, compatibility fallbacks, error
   handling, deterministic artifacts, anti-false-positive checks, and contract
   drift guards.
5. Look for false positives where the test may not exercise the new path.
6. Run unit tests yourself.
7. Run runtime or integration proof yourself.
8. Inspect generated proof artifacts, screenshots, logs, or browser output.
9. Add any final hardening found by proof inspection.
10. Record measured `Te` per phase and update local `alpha(phi)` priors.
11. Close the worker once accepted or superseded.

The parent must not hand back a raw worker patch when local wiring or hardening
is clearly needed. A TempoFastlane run is complete only after the parent has
converted the worker's slice into an integrated, verifiable repo state.

## When To Abort vs Iterate

Before abandoning a patch on the grounds that "iteration would take too long",
compute the corrected `Tc` for the iteration step. Iteration is almost always
cheaper than re-delegation because `Tp` is inflated by TIB.

Discard the patch and re-delegate with smaller scope when any of these appear:

- gross ownership violation;
- fabricated proof;
- broad unauthorized rewrite of files the patch was not supposed to touch;
- handoff claims pre-existing dirty files as newly created;
- repeated guessed command names after the parent supplied the real ones.

Iterate when:

- ownership was respected but proof signal is weak;
- wiring is missing but the core slice is correct;
- a single anti-false-positive check needs adding.

## Proof Contract

For every delegated feature, define two paths whenever possible:

1. Legacy path still works.
2. New path is exercised and leaves a different observable mark.

Examples:

- Generated smoke path: proof contains `runtime_smoke.source=generated`.
- Fallback smoke path: proof contains
  `runtime_smoke.source=generated-fallback` and `fallback_generated=true`.
- Cache miss path: log or proof contains `cache=miss`.
- Migration path: DB schema version changes and migrated data is still readable.

If existing behavior can mask the new path, require a force flag or
deterministic setup that makes the new path unavoidable.

When there is no runtime path, substitute the runtime contract with a
**structural diff snapshot**: a before/after capture of a public signature,
exported API surface, fixture shape, or generated contract file.

Temporal note on proof: do not reject a proof artifact on the grounds that it
executed too quickly. A smoke that completes in seconds is the wall-clock truth
correcting TIB, not a suspicious signal. Reject on causal content, not on speed.

## Anti-False-Positive Rules

Do not accept:

- "I removed X" if the generator recreates X before the relevant stage.
- "Unit tests cover it" when the claim is about runtime behavior.
- "Smoke passed" if the smoke used the old path.
- "Smoke failed" without checking whether the app, server, or runtime
  prerequisite was running.
- A guessed command name when the repo has a different script in `package.json`.
- A handoff that claims already-dirty files were newly created by the worker.
- Docs claiming success before proof artifacts confirm it.
- A duration claim stated without phase classification and `alpha(phi)` applied.

Require the worker to explicitly answer:

- What proves the new code path ran?
- Which proof file contains it?
- Which field, log line, status, or output confirms it?
- What could still be masking a false positive?
- Which commands were copied from repo scripts, and which were inferred?
- Which files were already dirty before it started?
- What was the measured `Te` per phase?
- Did this run reveal a reusable workflow improvement the parent should
  consider?

## Command And Runtime Preflight

Delegated tasks often fail for boring reasons: wrong script name, no dev server,
stale port, missing env, or a worker assuming a runtime is alive.

Before delegation, the parent should give the worker:

- exact command names copied from `package.json`, Makefile, task runner, or docs;
- required services and ports, for example `npm run dev` serving
  `http://127.0.0.1:7777`;
- whether the worker may start background services or should leave runtime proof
  to the parent;
- expected artifact paths for browser screenshots, logs, or proof JSON.

If a runtime command fails, the worker must classify it:

- `code-failure`: the patch broke behavior;
- `environment-blocker`: service, port, credential, or external runtime missing;
- `command-error`: command name or invocation was wrong.

The parent still reruns the final runtime proof independently.

## Coupling Rules: TEMPONIZER x Delegation

- Effort selection is a function of `alpha(phi) * Tp` and parental rework risk,
  not of intuitive task size. Reclassify before selecting a tier.
- Abort versus iterate is decided after computing corrected iteration cost. Most
  restart reflexes are TIB artifacts.
- Parallelism is mandatory for independent preparation steps. Spawn, baseline,
  grep, and command discovery share a single batch.
- Handoff requires `Te`. Per-phase wall-clock measurements feed the Living Skill
  Loop. "Done" without `Te` is an incomplete handoff when measurement was
  feasible.
- Proof speed is not a defect. Anti-false-positive review evaluates causal
  content, not duration.
- Skill updates are temporal-aware. Stable `Te` versus `Tp` drift per phase is
  itself grounds for proposing an `alpha(phi)` update, subject to the
  one-proposal-per-session limit.

## Prompt Template

Read `references/delegation-template.md` when preparing a worker task. It
contains a reusable prompt with context, ownership, acceptance criteria,
verification, handoff, and `Te` reporting sections.

Use the template as a starting point, then fill in project-specific paths,
commands, proof fields, risk notes, and expected phase classification.

## Case Notes

Field-tested lessons from real runs are kept in `references/case-notes.md`.
Read them when designing a new delegation, especially for generator work,
runtime or browser proof, medium-tier worker runs, or temporal recalibration
events. The examples there are illustrative; adapt to the artifacts native to
the current repo.

## Parent Gate Checklist

Group A: **Pre-acceptance**

- [ ] Parent used the correct spawn mode: model override without full fork, or
      full fork without override.
- [ ] Baseline dirty state was captured before delegation.
- [ ] Worker changed only owned files or justified exceptions.
- [ ] Worker did not claim pre-existing dirty or new files as newly created.
- [ ] Verification command names match actual repo scripts.
- [ ] Unit tests pass locally.
- [ ] Integration or runtime proof passes locally.
- [ ] The new behavior has a distinct proof signal, or a structural diff
      snapshot when no runtime path exists.
- [ ] Proof artifacts are named in the final report.
- [ ] Limitations are honest and not reframed as success.
- [ ] Per-phase `Te` was recorded when measurement was feasible.
- [ ] Any duration claim in the handoff was reported as `Tc` after applying
      `alpha(phi)`, not as raw `Tp`.

Group B: **Integration**

- [ ] Parent integrated the returned work with adjacent wiring required by the
      feature.
- [ ] Parent performed local hardening before declaring the lane accepted.
- [ ] The patch preserves existing CLI or API compatibility unless explicitly
      allowed.

Group C: **Post-acceptance**

- [ ] Repo-specific docs, changelog, release notes, checkpoints, scorecards, or
      public artifacts match verified behavior when those conventions exist.
- [ ] For a major checkpoint or category uplevel, the Artifact Sync Gate ran:
      update only repo-native public or method docs and evidence files that
      exist or are explicitly requested.
- [ ] If several runs exposed a repeated workflow pattern, the parent proposed a
      universal skill update or recorded why no update is warranted.
- [ ] If stable `Te` versus `Tp` drift was observed across runs, the parent
      considered an `alpha(phi)` prior update for this skill.

## Master Rule

Velocity without proof is a regression. Proof without temporal calibration is
TIB performing as discipline. TempoFastlane resolves both: temporal
self-correction unlocks empirically grounded velocity, and the delegation
protocol enforces ownership, causal proof, integration, and hardening over that
velocity. Apply both layers to every delegation, every effort selection, every
iterate-or-abort decision, and every handoff.