Restructuring & Feature Guide

1. The restructuring prompt

Review and reorganize the entire project structure to make it clean, logical, scalable, and easy to maintain. Separate core system/source code from Admin-Panel-managed project files; store all admin-managed content in a dedicated directory; keep two-way GitHub sync working; add a /documentation folder with a project doc and this feature/prompt doc; make the Admin Panel fully responsive; and preserve all existing functionality while verifying the app still builds and deploys.

The goal was a clear separation between the application's core files and the content the Admin Panel manages, without breaking the live launcher or admin.

2. Implementation steps

1. Introduced a single content root data/ and moved the old clients/ tree into a nested, scalable layout:

   clients/icon            → data/scripts/icon
   clients/stpm            → data/scripts/stpm
   clients/general-scripts → data/scripts/general-scripts
   clients/shared          → data/shared
   clients/_template       → data/templates
   clients/_docs           → data/documents

   Files were moved with git mv so history is preserved.
2. Updated every path reference (the launcher, the Admin Panel, and the api/list.js / api/get.js path guards) from clients/… to data/…. Because script sets now live in their own data/scripts/ folder, the old "filter out shared/_template/_docs" logic was removed.
3. Added public/documentation/ with this file and project-documentation.html.
4. Made the Admin Panel fully responsive — tablet and mobile breakpoints, an off-canvas sidebar drawer that auto-closes when you open a file or folder, and toolbars that stack on small screens.
5. Verified the launcher lists script sets, the Admin Panel loads the tree and files, and scripts run — end to end against the live deployment.

3. Features today

Launcher (PowerShell)

• One-command run: irm https://toolkit.bistab.com.np | iex.
• Live three-level menu (Script Set → Section → Script) built from data/.
• Arrow-key navigation with a highlighted row; number keys; B/H/Q.
• Optional password gate (LAUNCHER_KEY), prompted at startup.
• Per-script choice: run as current user, or run as Administrator (UAC, separate window).
• -Config passed only if the script declares it; robust JSON parsing; errors never crash the menu.

Launcher (Linux / bash)

• One-command run: curl -fsSL https://toolkit.bistab.com.np/linux | bash.
• Terminal menu built from data/linux (mirror of Scripts); browse set → category → script.
• Run / Run as root / View / Schedule (one-time via at); same x-launcher-key auth; input read from /dev/tty so it works under curl | bash.

Admin Panel (browser)

• Password login (ADMIN_PASSWORD); grouped tree (Script Sets / Doc Storage / Templates & Shared).
• Folder view with Import files (upload + drag-drop), + File, + Folder, Settings gear.
• CodeMirror editor with Copy, Save, Delete; per-row rename and delete.
• Password required for Save / Rename / Delete; config.json and .gitkeep hidden from view.
• Doc Storage (data/documents) for procedures/docs — admin-only, hidden from PowerShell.
• Fully responsive on desktop, tablet and mobile.

Platform

• Serverless proxy holds the GitHub token server-side; no-store on read endpoints closes a cache auth-bypass.
• Two independent gates (launcher vs. admin).

4. GitHub integration

The private repo is the data store. Adding files in git and editing in the Admin Panel are two sides of the same thing:

• git → app: push anything under data/ and it appears in the Admin Panel and launcher with the correct hierarchy on the next load (Trees/Contents API, no caching on reads).
• app → git: every Admin Panel Save / Rename / Delete / Import is a commit via the Contents API (admin: <action> <path>), so changes sync straight back with full history.

The functions authenticate to GitHub with GITHUB_TOKEN (fine-grained, this repo, Contents read+write). Writes include the file sha when updating; deletes require the sha.

5. Admin Panel workflow

1. Open /admin, sign in with ADMIN_PASSWORD.
2. New script set: + Script set (or the ＋ next to "Script Sets") → creates data/scripts/<name>/config.json.
3. Add sections/scripts: click the script set → + Folder for a section, then open the section and use + File or Import files.
4. Edit config: the ⚙ gear (tree) or Settings (folder view) opens config.json.
5. Store documents: use the Doc Storage section (＋ to add folders; drag-drop or Import files).
6. Save / Rename / Delete prompt for the admin password before committing.

6. Vercel deployment

1. Private GitHub repo → import into Vercel (no build settings).
2. Set env vars (Production): GITHUB_TOKEN (Contents read+write), GITHUB_REPO, optional GITHUB_REF, ADMIN_PASSWORD, optional LAUNCHER_KEY.
3. Redeploy after any env change.
4. Custom domain: point it at the project, set $script:BaseUrl in public/launcher.ps1, push once.

Verify: irm https://<domain> | iex shows the script set menu; /admin loads the tree and opens files.

7. Guidance for future development

• Keep the split: app code in api/ + public/; all managed content under data/. New content categories → new subfolders of data/ (mirror the launcher/admin grouping logic if they should be treated specially).
• Adding a launcher level or filter lives in public/launcher.ps1 (script sets from data/scripts, shared from data/shared). Bump $script:Version so deploys are verifiable.
• New admin capabilities go in public/admin/index.html (single file). Reuse the existing helpers: write(), askPassword(), loadTree(), renderFolderView().
• New API endpoints are new files in api/. Gate reads with LAUNCHER_KEY-or-admin, writes with ADMIN_PASSWORD; keep no-store on anything that returns gated content.
• Large binaries: the Contents API caps at ~1 MB. For bigger files, add a path backed by Git LFS or release assets rather than the Contents API.
• Path hygiene: the admin already trims names and rejects whitespace-padded segments (a trailing space breaks Windows checkout) — keep that guard in any new create/rename flow.
• Rotate secrets (token + passwords) on a schedule via Vercel env vars, then redeploy.