Code Rooms
---
name: tempofastlane
description: >-
Unified delegation and temporal-calibration protocol. Use when delegating
bounded implementation work to a worker model (`gpt-5.4` at medium or xhigh
reasoning by default, with Spark as an optional legacy lane when available)
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;
- drain or explicitly wait for active workers before editing any overlapping
implementation, wiring, test, or proof surface;
- attach or restate `agents/temponizer-preamble.md` at the start of every worker
prompt so temporal calibration is part of the worker's operating context, not
an optional reminder;
- apply the Universal Leverage Gate before splitting large work;
- 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.
## Universal Leverage Gate
Before delegating a large implementation, the parent should ask whether the
requested feature is an isolated instance or a sign of a broader capability
class.
If a smaller structural abstraction would unlock the class with less future
rework, delegate the structural boundary first. Put variable details in
contracts, manifests, packs, fixtures, configuration, or source-of-truth data.
Put repeated invariants in validators, adapters, executors, registries, gates,
or proof contracts.
Use this gate to avoid turning a fast lane into a pile of one-off features. The
best worker slice is often not "build this provider/button/page"; it is "build
the reusable boundary that this provider/button/page proves."
Ask before spawning:
- Is this a one-off leaf, or does it reveal a reusable branch?
- What remains constant across likely future variants?
- What varies and should stay outside the core?
- Which existing pattern, donor, standard, or prior proof teaches the
invariant?
- What is the smallest causal proof that proves the class without
overclaiming?
This gate does not replace proof discipline. It decides what to delegate; the
parent still owns wiring, hardening, independent verification, and honest
acceptance.
## 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. Legacy
Spark lanes may use the technical id `gpt-5.3-codex-spark` where explicit
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.
## Model Fallback Rule
Primary fast lanes use `gpt-5.4` with explicit reasoning effort:
- Medium lane -> `gpt-5.4` with `medium` reasoning.
- Xhigh lane -> `gpt-5.4` with `xhigh` reasoning.
Spark is an optional legacy lane when available and explicitly useful to the
parent. If a Spark or other legacy lane is unavailable, preserve the lane's
proof discipline and map it to the current default worker:
- Legacy/Spark `medium` lane unavailable -> `gpt-5.4` with `medium` reasoning.
- Legacy/Spark `xhigh` lane unavailable -> `gpt-5.4` with `xhigh` reasoning.
Use `gpt-5.5` only for extremely complex work with looser contracts or frontier
reasoning demands where the parent judges extra synthesis necessary. In those
cases, `gpt-5.5` with `xhigh` reasoning is allowed.
This is a lane-selection rule, not a quality-gate downgrade. The parent still
owns architecture, integration, hardening, independent verification, and proof
Default to `gpt-5.4` 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.4` 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
### Worker Wait Gate
After spawning a worker, the parent must treat the worker as the owner of its
assigned surface until the worker returns, is redirected, or is closed. If the
next parent step depends on the worker's answer, or could touch the same files,
symbols, proof artifacts, generated outputs, or public wiring, the parent waits
for the worker before continuing.
Allowed while workers run:
- cheap, read-only baseline capture that was not possible before spawning;
- waiting for other independent workers in the same lane;
- urgent interruption or redirection when a worker violates scope.
Avoid while workers run:
- implementing the same feature locally "just in case";
- editing adjacent wiring or tests that the worker may also update;
- spending large tokens redoing the delegated investigation;
- integrating partial assumptions before the worker handoff is available.
Trust the delegation by default. Parallelism is for independent work, not for
the parent to race its own sidecars. The smart parent minimizes duplicated
thinking, waits for the handoff when it affects the next step, then integrates
once with full information.
### Parallel Fastlane
Use Parallel Fastlane when the work naturally splits into several independent
lanes and the parent must supervise a broader construction wave without
duplicating the workers' micro-work.
Parallel Fastlane requires a shared preamble before spawning:
- current north star and mode;
- repo-native first commands and proof gates;
- active contracts, generated truth surfaces, and known non-claims;
- file ownership and forbidden surfaces for each lane;
- expected handoff shape, including proof fields and measured `Te`;
- instruction to refresh local truth sources when the worker detects stale
context, and to fall back to exact repo files when an external index is stale.
Run Parallel Fastlane only when write scopes are disjoint or when all but one
lane is read-only. If a lane must touch shared wiring, proofs, generated
outputs, docs, or public surfaces, make it the single writer for that surface
and force all other lanes to return plans or reviews.
The parent's job in Parallel Fastlane is orchestration, not parallel anxiety:
dispatch bounded lanes, wait or drain them at ownership boundaries, integrate
once, then run the proof gates. Do not keep spending large tokens redoing the
same investigation while workers are active.
### 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. Apply the Universal Leverage Gate for large or category-expanding work:
identify whether the worker should build a reusable boundary instead of a
one-off instance.
4. Decide spawn mode:
- To force `gpt-5.4` with xhigh or medium, spawn with `fork_context: false`
and embed full task context in the prompt.
- To use an optional legacy Spark lane, also spawn with `fork_context:
false` and specify the legacy model explicitly in the prompt.
- When full conversation history matters more, use `fork_context: true` and
omit model/effort overrides because forked agents inherit parent settings.
5. State the implementation goal in one paragraph.
6. Give explicit file ownership and forbidden surfaces.
7. Tell the worker it is not alone in the codebase and must not revert unrelated
changes.
8. Define acceptance criteria in terms of observable proof.
9. Require final handoff with files changed, commands run, proof artifacts,
exact proof fields, limitations, concerns, and per-phase `Te` if measurable.
10. For long or multi-agent waves, provide a shared pathos or preamble that
captures the north star, mode, current truth surfaces, non-claims, and
first commands. Keep it portable: no private local paths, secrets, or
one-off chat memory.
11. Issue independent preparation calls in parallel: spawn, baseline capture,
adjacent grep, and command discovery in one batch unless logically dependent.
12. Record active worker IDs and apply the Worker Wait Gate before any parent
implementation step that overlaps their ownership or depends on their
result.
### While The Worker Runs
- Prefer waiting when the worker owns the next relevant implementation surface.
- Do only small, demonstrably disjoint, read-only prep if it will reduce final
integration cost.
- If the worker runs longer than the corrected `Tc` would predict, inspect only
enough status to decide whether to keep waiting, redirect, or close it.
- 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 cheap publication and drift checks early when available: local path
markers, secrets, whitespace, stale docs, and artifact portability.
7. Run focused unit tests yourself.
8. Run runtime or integration proof yourself.
9. Inspect generated proof artifacts, screenshots, logs, or browser output.
10. Rebuild or check consumer truth surfaces before the full close.
11. Add any final hardening found by proof inspection.
12. Record measured `Te` per phase and update local `alpha(phi)` priors.
13. 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.
For long checkpoint-style runs, prefer a gate cascade over one giant final
validation pass: micro gate, focused tests, truth-surface refresh, early
reputation scan, full close, release/publication preflight. This keeps quality
constant while moving cheap failures earlier.
Keep artifact volume intentional. Separate generated outputs are justified when
they prove distinct causal surfaces; otherwise prefer one canonical output plus
surface-specific proof wrappers or transcripts.
## 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.
- Worker parallelism must include a wait/drain point before overlapping parent
implementation. Do not race sidecars on the same files, symbols, proof
artifacts, or public wiring.
- 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.
- [ ] Active workers were waited, redirected, or closed before parent edits to
overlapping implementation, wiring, test, proof, or generated surfaces.
- [ ] In multi-agent runs, every lane had a shared preamble/pathos, disjoint
write scope, and explicit forbidden surfaces.
- [ ] 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.
- [ ] Cheap reputation and drift checks ran before expensive full-close gates
when the repo provides them.
- [ ] Generated artifacts were reviewed for duplication; duplicates are either
causal evidence for distinct surfaces or intentionally omitted.
- [ ] 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.
