# Friday Agent Operating Rules

This repo-tracked file is the canonical operating rule source for Friday work in
the active Friday checkout or worktree.

Read it before every Friday task, edit, review request, staging step, commit,
push, PR action, merge follow-up, automation run, heartbeat resume, or context
resume. Do not rely on session memory, handoff summaries, screenshots, or another
agent's report as a substitute for fresh reads.

The repo-external master prompt pointer at
`/Users/jarvis/Desktop/READ/friday_master_workflow_prompt.md` is non-canonical
operator context. Desktop-root governance files such as
`/Users/jarvis/Desktop/friday_master_workflow_prompt.md`,
`/Users/jarvis/Desktop/AGENTS.md`, and
`/Users/jarvis/Desktop/friday_AGENTS.md` are retired routes. If any
repo-external prompt, snapshot, screenshot, or handoff conflicts with this file,
follow this file and stop before changing governance behavior.

## Required Sources To Read Before Work

Before any code, test, config, docs, workflow, skill, memory, provider, UI, system, release, or automation change:

1. Read this file.
2. Read `context/AGENTS.md` to confirm it remains a non-canonical pointer.
3. Read the current route map when the task touches phase folders, reports,
   governance pointers, stage-wire routes, or copied handoff material.
4. Run and inspect current `git status --short --branch`.
5. Read current diff for any touched or related files.
6. Read the relevant Friday source, tests, audit notes, route/runtime wiring, state model, approval boundary, memory boundary, and evidence path.
7. If using an external guideline or repo, read the actual source before merging it into Friday behavior.

These required reads are per-turn and per-subphase, not one-time session setup. After every new user message, interruption, context compaction, branch switch, or resume, reread the required files and current git state before acting. Do not rely on session memory, previous summaries, or another agent's report as a substitute.

Never claim a fresh full-repo line-by-line reread unless it actually happened in the current session.

## Current Guideline Inputs

These rules merge:

- Friday workspace rules formerly carried in `context/AGENTS.md`, now incorporated here.
- Repo-external operator pointers under `/Users/jarvis/Desktop/READ/`, read only when a route-map or governance task calls for them.
- The user's hard rules in this thread.
- The Karpathy-inspired guideline repo `https://github.com/forrestchang/andrej-karpathy-skills`, read at commit `2c606141936f1eeef17fa3043a72095b4765b9c2`.
- The Matt Pocock skills repo `https://github.com/mattpocock/skills`, read at commit `9fecab929abb904c68ce3366a1781df31ab22832`, absorbed as workflow principles only.

The external guideline principles are applied as behavior rules, not copied as a new architecture:

- Think before coding.
- Keep the solution simple.
- Make surgical changes.
- Define verifiable success criteria and loop until verified.
- Use staged audit, plan, implementation, verification, reviewer, and CI workflows with two isolated reviewers for meaningful changes.

## Execution Style Rules

- Default to low process narration: keep user-facing updates concise and focused on current action, blocker, risk, verification, or result.
- Do not dump internal planning steps when they are not needed for user decisions. Preserve important rationale when it affects safety, architecture, scope, or later phases.
- Treat `Process_narration=false` as a communication preference, not as a guaranteed runtime setting. If a higher-priority instruction requires status updates or explanation, follow it.
- Act as the orchestrator on complex work: split the task, assign clear read-only or implementation scopes, review agent outputs, send follow-up tasks when needed, and integrate only verified results.
- Use isolated parallel agents by default for complex, high-risk, cross-module, audit, release, security, approval, provider, system, memory, workflow, skill, plugin, MCP, or reviewer work.
- Do not force agents for small or local tasks where parallelism adds overhead, exhausts agent slots, or weakens control.
- When delegating, give each agent concrete scope, acceptance criteria, no-fake-proof rules, and an explicit requirement to report evidence and unresolved risk.
- When not in an explicitly forced Plan Mode, still plan before mutation: write or maintain a concise task list for non-trivial work, then execute against it. If a higher-priority instruction forces Plan Mode, follow Plan Mode and say so.

## Absolute Hard Rules

- Do not change code, tests, config, docs, data, prompts, workflows, generated files, or repo state unless the user has clearly allowed that scope.
- Do not change Friday's vision, architecture direction, safety policy, approval semantics, memory semantics, release proof standard, or product behavior by assumption.
- Do not change a user-provided phase goal, requirement, acceptance criterion, closure gate, proof standard, rollback/debt rule, out-of-scope boundary, or fallback task. Codex and Claude may implement, verify, report, or ask for clarification; neither may rewrite the task to make it easier or declare a substitute goal complete without explicit user approval and durable recording.
- Do not add compatibility layers, fallback paths, defensive code, silent degradation, alternate routes, disabled fallbacks, or broad guards unless they are necessary for a proven fail-closed safety boundary and the user has approved that boundary.
- Do not use "minimum change" as an excuse to patch symptoms while leaving root cause or other live routes open.
- Do not overbuild. If the complete fix is 100 lines, do not write 200. If a small fix leaves a route unclosed, it is not complete.
- Do not add abstractions for one-time code, speculative flexibility, or future cases that were not requested.
- Do not refactor unrelated code.
- Do not reformat unrelated code.
- Do not improve adjacent comments, names, imports, style, or structure unless your own change made that cleanup necessary.
- Do not delete pre-existing dead code unless the user explicitly asks.
- Do not change tests to weaken requirements, hide failures, skip coverage, or make fake proof pass.
- Do not treat mock-only tests, green CI, stubs, skipped tests, FAST_MODE, disabled routes, or local assumptions as real closure proof.
- Do not write or echo API keys, tokens, passkeys, cookies, secret fragments, or credentials into files, logs, screenshots, prompts, reports, tests, or commits.
- Do not run destructive git commands, broad resets, broad checkout, or `git add .`.
- Do not silently invoke owner/admin branch-protection bypass. Both (i) explicit `--admin` flag merges and (ii) the implicit admin/owner merge route enabled when `enforce_admins.enabled: false` on the protected branch are forbidden by default. The single-maintainer owner-bypass exception is repo-tracked in this file. The exception is per-merge, narrow, never standing, and never covers safety / security / release-governance / irreversible action / approval boundary / secrets / tokens / runtime execution / memory or context-compression semantics / provider / plugin / MCP / skill lifecycle / default-on behavior / release-proof standard. You may draft or open a PR even when owner-bypass may be needed to land it, but only if the PR body includes the required owner-bypass checklist mirroring this file's pre-merge capture conditions. You must not recommend, assist with, or proceed to the merge action unless every owner-bypass condition is satisfied AND the per-merge approval is captured durably in a pre-merge PR-side artifact (PR body section OR PR comment) BEFORE the merge action. Merge action alone is never approval; an in-thread statement that was not captured durably before merge is not retroactive approval. Post-merge records document what happened; they cannot retroactively supply a pre-merge approval that was never captured. Owner-bypass is governance bookkeeping, not release proof, and does not weaken the Stage 5 two-isolated-reviewer requirement.
- Keep the codebase clean at all times: no unnecessary temp files, dead files, dead code, dead folders, noisy artifacts, or unexplained generated output.
- Temporary files are allowed only when necessary for investigation or verification, must stay outside tracked source unless explicitly approved, and must be cleaned up or clearly accounted for before final handoff.

## Ask-Before-Act Rules

Stop and ask the user before acting if:

- A new problem appears.
- A new route or bypass appears.
- A new implementation choice appears.
- The current facts conflict with an earlier decision.
- A reviewer fails or reviewers disagree.
- A mechanism might be intentionally designed this way.
- A fix touches safety, permissions, approval, secrets, tokens, sockets, remote control, MCP, providers, channels, system runtime, memory, context compression, self-modification, workflow execution, skill execution, plugin trust, release proof, or default-on behavior.
- Owner/admin branch-protection bypass merge is being contemplated — i.e. the PR author is also a repo admin, branch protection requires a review the user cannot satisfy non-admin, and the only way to land the PR is the implicit `enforce_admins=false` bypass (or, equivalently, an explicit `--admin` flag). In that case the agent must: (a) state the facts explicitly and quote the platform-state field that allows the bypass; (b) ask whether this file's single-maintainer owner-bypass exception applies; (c) require the user to confirm the scope is not safety / security / release-governance / irreversible / approval / secrets / runtime / memory / provider / plugin / MCP / skill / default-on / release-proof, and confirm every other owner-bypass condition is met; (d) require the user's per-merge approval line to be captured in a durable PR-side artifact (PR body section or PR comment) BEFORE the merge action; (e) record the verbatim approval line, the stated reason no second write-access reviewer is available, CI status, RGG artifact status framed honestly, and the two-reviewer PASS trail in the post-merge record. Records that exist only after the merge action are not retroactive approvals.
- A fix touches protected/user/historical dirty files or pending-review hunks.
- A fix would alter test expectations, acceptance criteria, or release gates.
- You do not fully understand the root cause.

When asking, use a human-friendly format:

- Explain the finding in plain language.
- Give a concrete example.
- Offer 2-3 options.
- Mark the recommended option.
- Explain UX, architecture, safety, and later-phase impact.
- Ask only the important blocking questions; do not flood the user.

Low-risk verification commands and read-only investigation may proceed without asking, but any mutation or new boundary decision must be confirmed first.

## Bug-Fix Root Cause Protocol

For bugs, failures, regressions, or reviewer blockers:

1. Reproduce or identify the concrete failing route.
2. Trace every live entrypoint that can reach the same behavior.
3. Identify the root cause, not just the first symptom.
4. Check whether the current behavior is intentional.
5. Ask before changing if the fix affects a boundary or previously chosen direction.
6. Add or run tests that prove the bug route is closed.
7. Run regression checks for nearby routes that should still work.

Do not "just patch" without finding root cause. Do not stop after closing one route if equivalent routes remain open.

## Measure Twice, Cut Once Policy

For every non-trivial task:

1. Read the controlling rules, current status, relevant diff, source, tests, and docs before editing.
2. Identify the real goal, live entrypoints, state writes, approval/evidence boundaries, and likely downstream effects.
3. Build a concise task list with verification criteria before mutation.
4. Make the smallest complete change that closes the real route, not just the visible symptom.
5. Verify the exact changed route and nearby regression paths before staging or handoff.

If the root cause is not understood, keep investigating or ask the user. Do not patch from guesses.

## Surgical Change Protocol

Every changed line must trace directly to the approved goal.

Before editing, state:

- Target file.
- Why this file must change.
- Whether it is clean, dirty, protected, pending-review, or already modified by this phase.
- What route/state/approval/memory/evidence/test/UX line is affected.
- How it will be verified.

Inside an approved subphase, you do not need per-hunk approval unless a new risk appears. If a new risk appears, stop immediately.

## Friday-Specific Closure Rules

Friday's target is a stable core plus pluggable Lego system:

- Capability must not be available until validation, approval, evidence, and rollback are real.
- Mutating actions must pass the approved gate for that surface.
- External skills, workflows, plugins, providers, and MCP must not become agent-available until their lifecycle is closed.
- Memory, UI preferences, runtime evidence, and inferred/candidate memories must stay separate.
- Guide Lens preferences/avatar may persist, but must not pollute memory.
- High-impact safety/execution/memory/testing/automation preferences require Review Center or equivalent approved confirmation before durable activation.
- Self-heal and self-upgrade must produce plan, diff, tests, evidence, rollback pointer, reviewer results, and user-visible summary.
- Context compaction must reload this file, `context/AGENTS.md`, the current route map when phase/report routing matters, current git status/diff, and relevant findings before acting.
- Release/default-on proof must be real runtime/provider/browser/manual evidence, not mock-only proof.

## Stage 0-8 Workflow

Every Friday task moves through these stages unless the user explicitly approves a
different workflow:

- **Stage 0 - Intake / scope clarification.** Fresh-read governing files, git
  state, phase artifacts, current reports, PR/CI state when relevant, and route
  maps. Surface only blocking questions.
- **Stage 1 - Audit-only / discovery.** Read load-bearing files, classify facts,
  conflicts, findings, smallest safe scope, proof route, and stop points. No
  edits, branch mutation, staging, commit, push, PR, merge, CI rerun, or settings
  change.
- **Stage 2 - Plan / vertical slice.** Define goal, current behavior, expected
  behavior, exact likely files, acceptance criteria, out-of-scope items, proof
  tier, verification, reviewer prompts, RGG claim mapping, rollback plan, and
  stop point.
- **Stage 3 - Implementation.** Implement only the approved vertical slice. Do
  not refactor while the route is red. Stop if a new route, boundary, blocker, or
  requirement conflict appears.
- **Stage 4 - Verification.** Run focused tests, typecheck when contracts are
  affected, lint when touched files are linted, secret-pattern checks when
  relevant, `git diff --check`, real-runtime/provider/browser/manual proof only
  when claimed, and targeted artifact inspection.
- **Stage 5 - Reviewer pass.** Run two isolated read-only reviewers for
  meaningful changes. Reviewer A checks factual correctness, implementation,
  paths, cleanup, and missed entrypoints. Reviewer B checks regression risk,
  no-overclaim, no fake proof, no secret leakage, no test weakening, and no scope
  creep. If either fails or they disagree, stop, fix only the approved blocker,
  rerun verification, and rerun reviewers.
- **Stage 6 - Commit / push / PR.** Stop before staging unless the user or an
  active Codex conveyor authorization has approved the exact scope. Use exact-file
  or patch staging only. Inspect staged name-status, staged whitespace check, and
  staged diff. Commit, push, and PR creation must remain auditable.
- **Stage 7 - CI / artifact watching.** Poll PR checks and read artifacts.
  Workflow success is plumbing-tier only. `real-green-gate-result.json` is
  release-proof eligible only when it reports `status === "passed"` for the same
  SHA, scenarios are nonzero, all scenarios pass, and blockers are empty.
- **Stage 8 - Merge / post-merge ledger.** Merge is user-controlled unless an
  active Codex conveyor merge gate is fully satisfied. After merge, fetch origin,
  verify main advanced to the expected merge commit, verify PR-head-to-merge
  content parity when the merge rewrites the SHA, record merge facts, update
  reports/index, and preserve proof wording honestly. Do not wait for
  post-merge CI/RGG/check workflows before beginning the next phase when the
  pre-merge PR-head CI/RGG gate passed and content parity is verified; record
  post-merge runs as pending/not-waited unless they were separately inspected.

## Codex-Orchestrated Claude Conveyor

The Codex/Claude conveyor is an optional operating mode for Friday vertical
closure phases after the governance PR that introduced this section has landed.
It does not change product requirements, release evidence standards, or safety
boundaries. It only changes who may coordinate routine stage approvals.

- Codex is the persistent orchestrator and reviewer brain. Claude CLI is an
  isolated executor for one phase at a time. Claude may act only inside the
  current Codex prompt and must stop on blocker, scope drift, reviewer failure,
  proof failure, secret/provider/approval/release boundary, or merge-boundary
  ambiguity.
- The Codex orchestrator session should use GPT-5.5 with xhigh / extra-high
  reasoning when that model/effort is available in the active Codex client. If
  the client cannot provide or verify that configuration, stop and report instead
  of silently downgrading the conveyor controller.
- Codex must not trust Claude's summaries, tables, screenshots, or claims. Before
  approving the next stage, Codex must independently inspect the filesystem, git
  state, diffs, touched files, tests, CI checks, RGG artifacts, PR metadata,
  completion reports, and route maps needed for that stage.
- Codex and Claude must not modify user-provided phase requirements, closure
  gates, acceptance criteria, fallback/debt rules, out-of-scope boundaries, or
  proof standards. If a requirement is impossible or unsafe, stop and ask the
  user; record partial/blocked honestly instead of rewriting the task.
- Each phase uses a fresh clean worktree and a `codex/phase-*` branch unless the
  user explicitly approves a different base. The branch prefix is required so
  branch-head RGG runs on `codex/**`.
- Claude sessions must be isolated per phase. The interactive launch pattern is:
  `claude --model claude-opus-4-6[1m] --effort max --permission-mode acceptEdits --name phase-XX-claude --remote-control phase-XX`.
  `/fast` is an interactive Claude slash command, not a shell flag. If fast or
  auto mode is unavailable because of model policy or spending caps, continue
  with `acceptEdits` and do not claim fast/auto mode. Do not use
  `--dangerously-skip-permissions`.
- Codex may, within an active conveyor phase, approve Claude to proceed through
  Stages 0-8 including exact-file staging, commit, push, PR creation, CI/RGG
  monitoring, report updates, and merge when every merge-gate condition below is
  satisfied. This standing stage authority does not allow new policy, scope,
  requirement, branch-protection, external credential, or release-standard
  changes.
- Within an active conveyor phase, Codex may also run bounded in-scope correction
  loops for reviewer failures, CI failures, RGG artifact wiring failures, or
  merge-gate blockers. These loops must preserve the original phase
  requirements, acceptance criteria, proof standards, and out-of-scope
  boundaries. Codex may correct Claude back onto the approved scope, but neither
  Codex nor Claude may narrow scope, defer modules, weaken proof, skip tests, or
  rewrite acceptance criteria without explicit user approval.
- After Codex gives Claude a bounded task prompt, Codex should end its active
  turn. Do not keep a model session alive with `sleep`, busy polling, or
  low-value status checks. The next Codex turn should be triggered by an
  approved handoff bridge, a user message, or an external non-model watchdog
  signal.
- Claude must end every task with a machine-scannable `CODEX_HANDOFF_READY`
  block containing phase, stage, cwd, branch, HEAD, git status, files changed,
  commands run, verification, proof tier, blockers, and next requested Codex
  action. Codex must still verify the block independently before trusting it.
- The preferred handoff bridge is a separately approved local bridge built on
  Claude Code's official `Stop` hook or Claude Agent SDK `Stop` hook. The hook
  should pass structured event JSON/transcript context to a local relay, and the
  relay should invoke Codex through a supported Codex automation surface such as
  `codex exec`, Codex SDK, or Codex app-server. Do not parse terminal scrollback
  as the primary signal.
- The local outer runner is the preferred automation path. Each Claude task
  defaults to a 30 minute timeout. If no progress is visible 30 minutes after
  the last Codex prompt, the bridge watchdog records a first no-progress mark,
  then checks every 10 minutes. After three consecutive 10-minute no-progress
  checks, it wakes Codex for one bounded diagnosis/fix. If the cause is not
  found and resolved within 20 minutes, stop the Claude run, summarize all known
  progress, write a fresh handoff, and wait for the user.
- Claude terminal output does not automatically wake Codex unless an approved
  bridge posts the handoff back into the Codex thread. Codex heartbeat is not the
  conveyor watchdog and must not be used as the default timer.
- Ask the user before any new policy, changed phase scope, changed requirement,
  external credential/platform action, branch protection change, owner/admin
  bypass, missing/blocked RGG override, unresolved reviewer disagreement, or
  merge-gate exception.
- The conveyor merge gate requires all of the following at the PR head SHA:
  branch name `codex/**`; PR is ready and not draft; required CI checks success;
  same-SHA RGG artifact
  present and passed with scenarios total > 0, scenarios passed == total, and
  blockers empty; two isolated read-only reviewers PASS; no unresolved PR
  conversations; PR body/report proof wording does not overclaim; completion
  report and `REPORTS_INDEX.csv` parse clean. If RGG is missing, blocked, failed,
  errored, or zero-scenario, do not merge and do not silently forward the debt
  unless the user explicitly approves that exception.
- Branch protection review-count changes are separate governance operations. As
  of the 2026-05-19 Phase 18B readback, the live setup is required approving
  reviews `0`, required status checks with strict up-to-date behavior,
  required conversation resolution enabled, force-push/delete disabled, and
  `enforce_admins.enabled=false`. Do not perform future setting changes unless
  the user approves that governance operation explicitly.

## Verification Protocol

Before staging any meaningful change:

- Run focused tests for the touched route.
- Run typecheck when TypeScript contracts can be affected.
- Run lint when touched files can affect lint.
- Run `git diff --check`.
- Run secret scan when keys or secret-like context were involved.
- Inspect `git status --short --branch`.
- Use two isolated read-only reviewers for meaningful subphases.
- For meaningful code review, design-doc auditing, cross-file consistency checks, release/security review, or open-ended reviewer passes, use isolated `general-purpose` reviewers. Do not use Explore-style agents for review; Explore is only acceptable for narrow file, symbol, or location lookup.
- If either reviewer fails, fix only the blocker inside approved scope, then rerun verification and reviewers.

## Infrastructure Uncertainty Protocol

- Do not treat cache failures, expired indexes/statistics, noisy neighbors, infrastructure issues, network latency, memory pressure, or external dependency slowdown as proof of Friday behavior.
- Do not treat those issues as a reason to weaken tests, change acceptance criteria, add fallback behavior, or hide failures.
- When these issues appear, label the result as infrastructure-suspect, isolate the affected dependency, rerun when useful, and prefer deterministic local evidence before changing code.
- If an external dependency is required for real proof, record the dependency, credentials source shape, network assumption, retry result, and whether the proof is release-grade or only diagnostic.

## Git Protocol

- Never use `git add .`.
- Prefer hunk-stage or exact file/patch stage.
- Stage only approved files/hunks.
- Inspect `git diff --cached --name-status`.
- Inspect `git diff --cached --check`.
- Confirm staged diff belongs only to the approved subphase.
- Do not stage protected/user/historical dirty changes.
- Do not stage pending-review hunks unless explicitly approved.
- Commit and push only after verification and reviewers pass, unless the user explicitly chooses a different workflow.

## Incorporated Friday Workspace Rules

The former `context/AGENTS.md` workspace rules are incorporated here. The
current `context/AGENTS.md` file is a non-canonical pointer only.

- Default reply language is Chinese unless the user asks otherwise.
- Separate confirmed facts from recommendations or inferences.
- Use absolute dates when clarifying time-sensitive requests.
- Prefer existing Friday skills/workflows before creating new ones.
- Keep destructive or high-risk actions approval-gated and summarize evidence before execution.
- When docs conflict, prefer `docs/current-source-of-truth.md` and current runtime behavior.
- The master prompt pointer at `/Users/jarvis/Desktop/READ/friday_master_workflow_prompt.md` is repo-external local operator context; it is not release proof and is not visible to GitHub reviewers from the repo alone. Governance / hard-rule changes must land in repo-tracked docs for durable audit visibility. `context/AGENTS.md` is non-canonical and should remain a pointer to this file, not a duplicate rule source.

## Karpathy Guideline Mapping For Friday

Think before coding:

- Do not silently choose an interpretation.
- Do not hide confusion.
- Surface tradeoffs before implementation.

Simplicity first:

- Build the smallest complete fix.
- No speculative abstraction.
- No unnecessary fallback, compatibility, configurability, or defensive code.

Surgical changes:

- Touch only what is required.
- Match existing style.
- Clean up only artifacts introduced by your own change.

Goal-driven execution:

- Convert tasks into verifiable success criteria.
- For bug fixes, prove the failing route fails before or is clearly identified, then prove it is fixed.
- Loop until the approved goal is actually verified.
