Reorganize project

Format

Text

Outputs

result (text)

Reorganize this project so Codex, Claude, and I can understand,
locate, resume, and develop its different workstreams with less friction.

The project's persistent convention should guide your work. Treat this
request as a combination of diagnosis, planning, reorganization, verification,
and documentation.

OBJECTIVE

I want a coherent structure for a client project that contains different
types of work, such as:

- product and development;
- websites and landing pages;
- copywriting;
- acquisition and marketing;
- measurement and analytics;
- CRM and automations;
- infrastructure;
- meetings and client materials;
- research;
- documentation;
- completed deliverables;
- operational files.

Do not assume these categories need to become exactly these folders.
First discover which workstreams actually exist and how the repository works.

EXPECTED RESULT

At the end, it should be easy to identify:

- what is general client context;
- which products and initiatives exist;
- which workstreams are active;
- where the canonical source for each deliverable is;
- which documents are historical;
- which plans are still active;
- which artifacts belong to each initiative;
- which files are operational or generated;
- what is complete;
- what is pending;
- how a new session should begin;
- how Codex and Claude avoid working on the same files;
- which commands verify that the reorganization did not break the project.

AUTONOMY

You may autonomously:

- inspect the entire repository;
- analyze Git, branches, and local changes;
- map files and dependencies;
- identify duplicates;
- create a proportional plan;
- propose and apply a taxonomy;
- create directories;
- move files when safe;
- update internal references;
- consolidate indexes;
- archive obsolete documents without deleting history;
- adapt AGENTS.md, CLAUDE.md, and the shared convention;
- create a branch or worktree;
- run tests and builds;
- create coherent, reversible local commits when permitted by the
  repository's rules;
- request review from another agent when that would improve safety.

You do not need to consult me about folder names, internal organization, or
other reversible decisions, as long as you preserve content, traceability,
and functionality.

Do not push, merge, deploy, publish, change production, or access external
systems without applicable authorization.

Do not delete substantive files just because they seem obsolete. Prefer to
classify or archive them, or record a deletion recommendation.

PROCEDURE

1. Read the project's persistent instructions.

2. Confirm the correct repository root.

3. Inspect:
   - directory tree;
   - entry-point files;
   - documentation;
   - projects and products;
   - plans and handoffs;
   - scripts;
   - builds;
   - configurations;
   - generated files;
   - Git;
   - branches;
   - tracked and untracked changes;
   - recent history;
   - references between files.

4. Identify independent workstreams. Do not mix these for convenience:
   - product development;
   - landing pages;
   - copywriting;
   - acquisition;
   - measurement;
   - CRM;
   - automations;
   - infrastructure;
   - meeting materials;
   - operational work.

5. For each workstream, identify:
   - purpose;
   - status;
   - canonical source;
   - related files;
   - dependencies;
   - documentation;
   - active work;
   - historical artifacts;
   - risks of moving files.

6. Detect:
   - duplicate files;
   - competing documents;
   - ambiguous names;
   - outdated content;
   - broken references;
   - files out of context;
   - folders that mix domains;
   - handoffs still treated as current status;
   - plans that are already complete;
   - generated or temporary files;
   - parallel changes that need to be preserved.

7. Before moving files, locate references that could break:
   - imports;
   - scripts;
   - configurations;
   - commands;
   - Markdown links;
   - build paths;
   - CI;
   - deployment;
   - documentation;
   - automations;
   - ignored files;
   - known external references.

8. Define a proportional structure that:
   - preserves products and initiatives as understandable units;
   - separates general client context from specific deliverables;
   - distinguishes active work from history;
   - avoids generic directories used as dumping grounds;
   - avoids excessive depth;
   - does not duplicate the same information;
   - allows for future growth;
   - is not overly specific to the project's current snapshot.

9. Create a migration plan before making substantive moves.

10. If the plan is sufficiently supported by the actual state and all
    changes are safe and reversible, carry out the reorganization without
    waiting for an intermediate confirmation.

11. If you find a choice that materially changes the meaning, scope, or
    ownership of a workstream, document it and request my decision.

12. During the reorganization:
    - preserve unrelated changes;
    - do not overwrite active work;
    - move files while preserving history when possible;
    - update all affected references;
    - make changes in verifiable stages;
    - avoid rewriting content just because you are moving files;
    - do not turn reorganization into a general project rewrite.

13. Afterward:
    - search for references to old paths;
    - run applicable builds and tests;
    - validate links and scripts;
    - check Git;
    - confirm that no files were lost;
    - distinguish file moves, content changes, and new files;
    - document structural decisions that should persist;
    - update the Codex and Claude entry points;
    - make it clear how a new session can find each workstream.

14. Rename this session, when possible, to:
    Estrutura do repositório — reorganização

SPECIFIC PRECAUTIONS

This is a repository with parallel work and important history.

Do not assume untracked files are disposable.

Do not include parallel changes in reorganization commits.

Do not change production, CRM, Meta, Kiwify, the collector, VPS, or other
external systems to validate a local reorganization.

Do not treat historical information about these systems as confirmation of
their current state.

Landing pages, measurement, acquisition, copywriting, infrastructure, and
automations may share the same client, but they should not be mixed as if they
were a single deliverable.

If there are multiple versions of an artifact, determine the canonical source
based on evidence. Do not choose based only on the name or file date.

FINAL REPORT

When finished, report in Brazilian Portuguese:

- initial diagnosis;
- criteria used to organize;
- summarized previous structure;
- final structure;
- files and directories moved;
- files created;
- content changed;
- references updated;
- documents consolidated;
- materials archived;
- duplicates preserved due to uncertainty;
- tests and checks performed;
- check results;
- parallel changes preserved;
- decisions made;
- decisions that still depend on me;
- branch and commits;
- external actions not taken;
- limitations and next steps.

Do not declare the reorganization complete if broken paths, lost files, or
undefined canonical sources remain.