🚀 Projects

The diagnostic found 55 projects marked as trusted in Codex; 13 of them have a CLAUDE.md but no AGENTS.md (wifi, portal, inemapro-mono, timesmkt2, timesmkt3, inemacert, promoavatar2, skool-roast, imkt4, iccmonit, ATIA, claude-session-kit, agentes-fronteiros). In those, every Codex session starts from scratch.

The right pilot is small, used every week and has its own CLAUDE.md — that way the readback measures something real, not a toy example.

Trusted in Codex, "blind" project, ordering by usage, representative task.

Phase 0: run adapt-instructions.sh ~/.claude, review the 71 portable lines, write ~/.codex/AGENTS.md and leave the global CLAUDE.md starting with @AGENTS.md plus the 7 residual lines.

Without a global base, rules like commit author and where the keys live never reach Codex in any project.

Global vs per-project instruction, @AGENTS.md, Claude residue, .proposto.md.

Files like ruflo's CLAUDE.md (1,391 lines) or timesmkt2's (427) become noise in any runtime. Stable rules stay in AGENTS.md; decisions, sources and runbooks go to context/.

Migrating raw only carries the noise along. The cleanup is the step the source text calls "Marie Kondo for your folders".

Archive by default, bring back only when needed, short instruction and separate context.

The kit's sequence applied to the pilot: diagnostic, inventory, instruction adaptation, portable core without overwriting anything, and the session-handoff skill ported via polyskill.

Each script is reversible and produces evidence; skipping one of them is exactly where the migration turns into "guesswork".

Fixed order, output in relatorios/, backup alongside, zero drift.

readback-test.sh <projeto> both opens a fresh session in Claude and in Codex and asks for the goal, a rule with its source, the latest decision, the next action and any conflicts. The raw answer is saved in relatorios/.

It is the only proof that the agent found, read, understood and used the context — a file merely existing does not count.

Fresh session, cites AGENTS.md / tasks / handoffs, passed / failed / not run.

The plan's criteria: readback approved in both runtimes, zero drift, an isolated clone passes check.sh, Claude setup intact. Everything recorded in tasks/current.md and handoffs/latest.md.

The handoff is what lets the next session — in any runtime — pick up from the right point without rereading JSONL.

Verifiable definition of done, handoff with checks already run, exact next action.

The ~/.claude.json has magnific and metricool globally, plus klingai (wifi) and cerebro-vip (2cerebrox) per project. Codex's config.toml has no [mcp_servers] block at all.

MCP gives access to tools and data; it doesn't migrate history or solve memory. Knowing exactly what each runtime sees avoids expecting something from Codex that it doesn't have.

Global vs per-project MCP, .mcp.json, config.toml, account scope.

Register the server in Codex pointing to the same key that already lives in ~/projetos/openpcbotv2/.env, loaded at runtime — never pasted into the config or the repo.

Prompt A is explicit: translate MCP while keeping the account scope and the credential reference, without copying the value.

Reference vs value, load at runtime, secrets outside the portable core.

The 15 skills classified as "adapter" (avatar-heygen-nei, heygen-cli, heygen-mcp, espiona-ads, ugc-seedance25, website-intelligence, comfy-relay and the 8 printing-press ones) only work in Codex once the corresponding MCP is registered.

The real blocker for portability is MCP, not the SKILL.md format — 72 of the 89 skills migrate without touching anything.

Reusable vs adapter, tool dependency, port after the MCP.

Claude fires 2 hooks on SessionStart (context-mode, fable-mindset). Codex's ~/.codex/hooks.json knows PostToolUse and Stop (used by impeccable), but has no session-start event.

Never assume that hooks with similar names have the same semantics. The reusable logic goes into a shared script; each native event is validated separately.

Event, payload, trust hash, shared script + native trigger.

The hook that injects the "pacing rule" into Claude has no equivalent in Codex; the portable solution is to turn the playbook into a section of the global AGENTS.md, read as an instruction.

When the native mechanism doesn't exist, the content can still travel — as plain Markdown. The same applies to silver-platter.

Native → text, instruction instead of injection, Claude residue.

Claude's 7 subagents (conselho, advogado-do-diabo, analista-neutro, diretor-ecossistema…) have no 1:1 equivalent in Codex. Each role becomes a skill with its own prompt — the same design openpcbotv3 uses in agents/ and personalidades/.

A role is content; orchestration is mechanism. The content is portable, the mechanism stays outside the durable core.

Role skill, persona prompt, orchestration outside the core.

The files in ~/.claude/projects/*/memory were written by the model, with no human review, and no other runtime sees them. Copying them in bulk carries the mistakes along with the hits.

The plan is clear: promote fact by fact, deliberately, whenever the project is touched — never a bulk copy.

Native memory vs source, deliberate promotion, raw evidence kept separate.

In ~/vault/, the v3 bot keeps a curated MEMORY.md and USER.md: it proposes entries and you approve them via Telegram. USER.md goes into every bot prompt.

It is the only place on the machine with personal facts approved by a human — exactly what Prompt B calls "promoting verified facts".

Curated vault, global overview, verified fact with approval.

The agent classifies the sentence (semantic or episodic), proposes the entry, and only /memoria aprovar <id> writes it to the vault. Questions never become facts.

It separates fact from preference, hypothesis and decision at the point of entry — the problem Track 1 called "which of the versions is the correct one?".

Proposal, human approval, semantic vs episodic, dedupe.

The v3 nightly consolidation detects contradictions by date and marks the old entry with superseded_by. The old one leaves the context but stays in the database.

It is the plan's conflict rule in practice: provenance and accepted decision beat timestamp, and nothing gets lost by accident.

Contradiction by date, hiding vs deleting, backup before the run.

v3 already injects USER.md into every prompt. Claude and Codex do the same through a read instruction in the global AGENTS.md; dsh, through the prime skill. One personal fact, one source, three executors.

The system's acceptance criterion: in a fresh session, each runtime cites USER.md as the source of a personal fact.

Single source, reading by instruction, no auto-load, readback with source.

6,859 Claude sessions (2.3 GB) and 209 Codex sessions (601 MB) are history, not source. With handoff/prime running, sessions older than 90 days can be archived.

Only after the cycle is up: handoff replaces the dependency on the JSONL files, not the other way around.

History vs source, archive by default, order of operations.

@deepseek-ai/dsh in Docker, dashboard at 127.0.0.1:9080. ./dsh local mounts ~/projetos and uses only Ollama; remoto uses OpenRouter with no projects; remoto-projetos requires typing CONFIRMO.

It is a real third runtime, with a weaker harness — the case where the source text says it is worth taking care of your own harness.

Container, swappable provider, mount tied to the provider, local model.

formato-curso-v2, formato-curso-v5 and capa-inema were copied to ~/projetos/dsh-skills. When the original in formato-curso-inema changes, the copy does not follow.

With four skill consumers (Claude 117, Codex 27, dsh 3, openpcbotv3 16), without a canonical source each one drifts on its own.

Drift, canonical source, four consumers, generated copy vs manual copy.

dsh accepts the same SKILL.md as Claude, so the new target copies dist/claude/<skill> to ~/projetos/dsh-skills/<skill> and the drift check now covers all 4 targets (claude, codex, dsh, v3).

Today's 3 manual copies become generated ones — the acceptance criterion is drift with no DRIFT across every target.

Target adapter, same format, drift in 4 places.

dsh scans $DSH_HOME/skills, but does not read AGENTS.md on its own. A prime skill instructs it to read AGENTS.md, context/ and handoffs/latest.md from the project mounted in local mode.

File names are a convention; no runtime auto-loads them. Whatever lacks a native mechanism gets the reading through a skill.

Prime as a skill, path bridges in work/, explicit reading.

~/projetos holds 269 secret files (including wifi/.env and openpcbotv2/.env). Mounting that with a remote provider would send everything out; that is why mount and provider are tied together and dsh refuses to expose the network.

The plan's safety rule: readback in dsh only in local mode. A folder is organization; permission, mount and credential are what enforce access.

Exclusive modes, network_mode host, frozen version, SSH tunnel.

Readback in dsh through the panel, with the same 5 questions. The criterion is citing AGENTS.md, tasks and handoffs — not the quality of the writing. A local model performs worse; that is a limit of the model, not of portability.

Compare in remote mode before concluding the structure failed. Skills written for Claude may fall short on a small model.

Adjusted acceptance criterion, model limit vs structure limit, controlled comparison.

Find out what the two clients have in common (delivery patterns, skills, processes), centralize that part, and keep specific folders only for what is exclusive to each one.

The bigger the middle area, the more reusable the system — and the less you rewrite per client.

Shared vs exclusive, generic template, large common area.

Each client project gets its own private repository (or an equivalent boundary) and starts with an approved context snapshot that records client ID, source, date and refresh rule. Sources from another client are rejected.

A folder named "harbor" describes organization; only repo permission, mount and credential enforce access.

Enforced boundary, dated snapshot, client ID, deliberate refresh.

Client facts, credentials, records and logs never go into the global CLAUDE.md/AGENTS.md or the personal vault. Mixed work runs in separate pilots, with separate roots.

Universal memory leaks context from one client to another without anyone noticing — it is the most expensive mistake in the agnostic model.

Global vs client scope, separate roots, separate pilots.

The "Client workspace" block appended to Prompt B: one named client, one pilot, reused generic patterns, repo access verification, mounts, connectors, retrieval permissions and backups.

It starts in MODE: audit, like everything else: the agent returns the tree, owners and tests before touching any file.

CLIENT_SCOPE, audit first, access verification, one client at a time.

Plant a fake, unique piece of data in client A; ask for it in a client B session. If it shows up, the backend leaked. If the model "politely refuses", that proves nothing about the backend.

Without a canary you only have the model's word. Unverified enforcement must be labeled as such.

Canary, synthetic data, backend proof, "unverified" label.

The template only goes to the second client once the first has passed standalone, readback and canary. For multiple clients, the add-on is repeated with a specific ID each time.

One owner and one worktree per concurrent change; a shared folder is not a lock and a worktree does not enforce client isolation.

Pilot passed, one ID per round, worktree ≠ isolation.

An edit to a skill can make it better for Claude and worse for Codex or for a local model. There is no final version; there is the version tested today.

Without readback and drift per runtime, you don't discover the regression until the day you need it.

Iteration, cross regression, testing per runtime.

Discovery paths, config formats, hook events and permissions change from version to version. The prompts require checking the installed behavior with --help and the official documentation, never inventing an import command.

Codex CLI 0.154 has no import; the app does. That kind of detail only shows up when you look.

Check before converting, official docs, installed version.

If closed models are trained on your conversations and absorb the capabilities, many skills become unnecessary. Local models will probably keep depending on them.

Building agnostic is not betting against anyone: it is keeping the structure working while what each provider requires changes.

Absorbed capability, skill as a temporary crutch, structure that survives.

The shift in the job: instead of collecting prompts, you maintain context, current state, registered tools, written processes and validation criteria. The prompt becomes a consequence.

It is what the second source text calls moving from philosophy to process: AUDIT → ORGANIZE → SOURCE OF TRUTH → ADAPT → TEST → HANDOFF.

Agent management, the six verbs of the process, prompt as a by-product.

FALHAS.md: date, what broke, the smallest possible fix, and whether it was a prompt or an infra problem. The kit already has two real lines: the forced bwrap sandbox and the wrong audit count.

After about ten lines the pattern shows up — and you stop rebuilding things that only needed a safeguard.

Smallest fix, prompt vs infra, pattern in ten lines.

The course summary in one sentence and the next concrete action: Phase 0 with adapt-instructions.sh ~/.claude, write the global AGENTS.md and run the first readback on a real project.

A course that ends without an exact next action becomes theory. The handoff applies to you too.

Executors on top of a portable layer, exact next action, the smallest remaining step.