chore: consolidate documentation — delete status/fix/progress cruft
Before: 335 tracked .md files; top level had 14 README-like docs; docs/ contained ~234 files, most of them auto/LLM-generated status reports (ALL_*_COMPLETE*, *_FIX*, DEPLOYMENT_*_FINAL*, etc.). After: 132 tracked .md files. Repo now has exactly five top-level docs: README.md, QUICKSTART.md, RUNBOOK.md, CONTRIBUTING.md, CHANGELOG.md (moved up from docs/). Keeper philosophy in docs/: - API, CCIP (ops + security + receiver/router refs), Chainlist refs, compliance, deployment (guides not status), database connection, legal compliance, metamask integration, production checklist, tiered-architecture implementation/setup, reusable-components plan, token-mechanism doc, wrap-and-bridge operational reference, plus docs/specs/** and docs/api/ / docs/openapi/ trees. Deleted (git history preserves provenance): - All 'ALL_*_COMPLETE*' / '*_FIX*' / '*_FIXED*' / '*_FINAL*' / '*_STATUS*' / '*_PROGRESS*' / '*_SUMMARY*' files. - BLOCKSCOUT_*_FIX / _CRASH / _INITIALIZATION / _SCHEMA / _YAML / _SKIP / _NEXT_STEPS / _START_AND_BUILD / _DATABASE_CREDENTIALS (the last contained passwords). - CCIP_IMPLEMENTATION_* / CCIP_CURRENT_STATUS / CCIP_GAP_* (gap analyses are not a sustained reference). - NPMPLUS_CREDENTIALS_GUIDE.md (contained creds). - LETSENCRYPT_CONFIGURATION_GUIDE.md (contained creds; will be re-introduced as runbook content post-secrets-scrub). - docs/diagnostic-reports/, docs/feature-flags/ (run-time artifacts). README.md: dead links (START_HERE, README_DEPLOYMENT, COMPLETE_DEPLOYMENT, DEPLOYMENT_COMPLETE_FINAL) replaced with links to the five canonical top-level docs + docs/ index.
This commit is contained in:
@@ -1,98 +0,0 @@
|
||||
# Setting Up Explorer as Git Submodule
|
||||
|
||||
## Current Status
|
||||
|
||||
The explorer monorepo has been created and initialized as a git repository. It's currently configured as a local submodule.
|
||||
|
||||
## Converting to Remote Repository (Recommended)
|
||||
|
||||
To make the submodule work properly with remote repositories:
|
||||
|
||||
### Step 1: Create Remote Repository
|
||||
|
||||
1. Create a new repository on GitHub/GitLab/etc:
|
||||
- Name: `chain-138-explorer`
|
||||
- Description: "Blockchain explorer for ChainID 138"
|
||||
|
||||
### Step 2: Push Explorer to Remote
|
||||
|
||||
```bash
|
||||
cd explorer-monorepo
|
||||
|
||||
# Add remote
|
||||
git remote add origin https://github.com/yourusername/chain-138-explorer.git
|
||||
|
||||
# Push to remote
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
### Step 3: Update Submodule Reference
|
||||
|
||||
In the parent project:
|
||||
|
||||
```bash
|
||||
cd /home/intlc/projects/proxmox
|
||||
|
||||
# Update .gitmodules
|
||||
cat > .gitmodules <<EOF
|
||||
[submodule "explorer-monorepo"]
|
||||
path = explorer-monorepo
|
||||
url = https://github.com/yourusername/chain-138-explorer.git
|
||||
EOF
|
||||
|
||||
# Update submodule reference
|
||||
git submodule sync
|
||||
git add .gitmodules
|
||||
git commit -m "Update explorer submodule to use remote repository"
|
||||
```
|
||||
|
||||
## Using the Submodule
|
||||
|
||||
### Clone Parent Project with Submodule
|
||||
|
||||
```bash
|
||||
git clone <parent-repo-url>
|
||||
cd proxmox
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
### Update Submodule
|
||||
|
||||
```bash
|
||||
# Update to latest
|
||||
cd explorer-monorepo
|
||||
git pull origin main
|
||||
cd ..
|
||||
git add explorer-monorepo
|
||||
git commit -m "Update explorer submodule"
|
||||
```
|
||||
|
||||
### Work on Submodule
|
||||
|
||||
```bash
|
||||
cd explorer-monorepo
|
||||
# Make changes
|
||||
git add .
|
||||
git commit -m "Your changes"
|
||||
git push origin main
|
||||
cd ..
|
||||
git add explorer-monorepo
|
||||
git commit -m "Update submodule reference"
|
||||
```
|
||||
|
||||
## Local Development (Current Setup)
|
||||
|
||||
If keeping it as a local submodule:
|
||||
|
||||
1. Work directly in `explorer-monorepo/`
|
||||
2. Commit changes normally
|
||||
3. The parent project will track the submodule state
|
||||
|
||||
## Benefits of Monorepo Structure
|
||||
|
||||
1. **Organization**: Clear separation of concerns
|
||||
2. **Versioning**: Independent versioning of explorer
|
||||
3. **Reusability**: Can be used in other projects
|
||||
4. **Deployment**: Standalone deployment scripts
|
||||
5. **Documentation**: Self-contained documentation
|
||||
|
||||
Reference in New Issue
Block a user