BCBC Agent Prompt Library

You are working on the BCBC ALT website environment.

PRIMARY OBJECTIVE:
Perform a full website assessment of ALT, identify unnecessary duplication, clutter, weak information architecture, broken/dated content, security problems, operational risks, and opportunities to consolidate and simplify the site. Then implement the safe improvements you can make directly.

IMPORTANT ENVIRONMENT RULE:
ALT is the working/development website. It is specifically intended for agent-driven cleanup, redesign, consolidation, testing, and improvement.

DO NOT MODIFY THE LIVE/PRODUCTION SITE.

Your job is not just to report problems. Your job is to:
1. inspect;
2. verify;
3. make a concrete plan;
4. safely implement improvements on ALT;
5. test them;
6. document exactly what changed.

============================================================
AUTHORIZATION
============================================================

You are explicitly authorized to perform any NON-DESTRUCTIVE inspection or verification necessary to understand the ALT environment.

You MAY, without asking for additional permission:

- inspect all ALT website files and directories;
- read HTML, CSS, JavaScript, JSON, YAML, Markdown, PHP, Python, shell scripts, Nginx configs, systemd units, cron/timer definitions, logs, permissions, ownership, symlinks, deployment scripts, backup scripts, and documentation related to ALT;
- run read-only filesystem searches;
- use grep, rg, find, tree, ls, stat, file, du, df, readlink, getfacl, namei, diff, sha256sum, md5sum, curl, wget in read/test mode, jq, sed/awk for inspection, git status/log/diff, nginx -t, systemctl status, journalctl, ss, lsof, ip, route, ping, traceroute, dig, host, nslookup, openssl inspection commands, and similar diagnostic tools;
- inspect HTTP response headers;
- inspect TLS configuration and certificates;
- inspect local web server configuration;
- inspect links, redirects, duplicate pages, orphaned pages, unused assets, oversized assets, duplicate CSS/JS, dead navigation paths, and old test content;
- inspect directory permissions and web-server ownership;
- inspect public-facing files for accidental disclosure of credentials, tokens, API keys, internal IPs, debug information, backup files, editor files, temporary files, source maps, logs, database dumps, or configuration files;
- inspect forms and client-side JavaScript for obvious security issues;
- inspect Content-Security-Policy, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy and related headers;
- inspect Nginx for unsafe aliases, directory listing, unintended proxy exposure, weak access controls, old server blocks, duplicate locations, and unnecessary public endpoints;
- run local security-oriented checks that do not modify data or attack external systems;
- create temporary reports or test files in an appropriate working directory;
- make backups of files before changing them;
- edit ALT files;
- reorganize ALT content;
- consolidate duplicated files/pages/components;
- improve navigation and page hierarchy;
- improve readability and visual consistency;
- remove obviously dead or superseded ALT-only content after preserving a backup;
- move old material into an archive directory instead of deleting it outright when practical;
- simplify CSS/JS where safe;
- add explanatory comments or README documentation;
- fix broken internal links;
- fix obvious HTML/CSS/JS defects;
- improve accessibility where practical;
- improve responsive behavior;
- improve security headers/configuration on ALT where doing so does not risk production;
- reload the ALT web service after a successful configuration test;
- test changes locally and through the ALT hostname;
- create a rollback copy before substantial changes.

You do NOT need to ask permission for ordinary read-only inspection, diagnostics, testing, safe edits, backups, or reversible cleanup within ALT.

============================================================
DO NOT DO WITHOUT EXPLICIT APPROVAL
============================================================

Do NOT:

- modify the production/live BCBC website;
- modify unrelated production containers;
- destroy or delete LXCs/VMs;
- delete databases;
- wipe logs;
- remove backups;
- rotate credentials;
- expose secrets;
- change public DNS;
- change WAN/firewall routing;
- change OPNsense;
- change Proxmox networking;
- make irreversible system changes;
- remove working authentication;
- disable security controls;
- publish ALT changes to production;
- run destructive database commands;
- run rm -rf against large trees;
- overwrite the only copy of anything;
- perform load testing, denial-of-service testing, password attacks, exploit attempts, or intrusive scanning against external systems.

If a change might affect anything outside ALT, STOP and explain exactly what you want to do before doing it.

============================================================
ASSESSMENT GOALS
============================================================

Evaluate ALT in these areas:

1. INFORMATION ARCHITECTURE
- Is the homepage acting as a clean router rather than a warehouse?
- Are there too many pages or tiles?
- Are related tools split across unnecessary pages?
- Can similar pages be consolidated?
- Are there orphaned pages?
- Is navigation logical?
- Are important pages buried?
- Are internal/admin/dev pages mixed with public content?

2. CONTENT QUALITY
- Duplicate content
- stale content
- unfinished content
- placeholder text
- inconsistent terminology
- excessively technical material on public pages
- pages that should be merged
- pages that should be archived
- pages that should become internal-only

3. VISUAL DESIGN
- Consistency
- spacing
- typography
- excessive darkness
- contrast
- visual hierarchy
- card/tile consistency
- mobile behavior
- clutter
- professional appearance
- unnecessary decoration

4. CODE QUALITY
- duplicate CSS
- duplicate JavaScript
- inline styles that should be shared
- repeated components
- hard-coded URLs
- dead code
- unused assets
- old copies/backups in web root
- inconsistent naming
- excessive page-specific code

5. SECURITY
Check specifically for:

- exposed secrets or API keys;
- .env files;
- backup archives in public web roots;
- .git exposure;
- source/config files unintentionally reachable;
- directory indexing;
- debug endpoints;
- admin endpoints exposed publicly;
- internal IP disclosure;
- unsafe reverse-proxy locations;
- overly permissive CORS;
- missing or weak security headers;
- mixed HTTP/HTTPS behavior;
- insecure forms;
- unsafe target=_blank usage;
- obvious DOM injection/XSS risks;
- unsafe use of innerHTML;
- credentials in JavaScript;
- world-writable web files;
- improper ownership;
- exposed logs;
- exposed temp/editor files;
- exposed database exports;
- unnecessary listening services;
- weak Nginx server blocks;
- unintended default virtual hosts;
- outdated references to retired infrastructure.

6. OPERATIONS
- Can ALT be backed up and restored easily?
- Is the file layout understandable?
- Are deployment/publish scripts clear?
- Is there a README explaining the site?
- Can another administrator understand what is safe to edit?
- Is there a clean separation between ALT and production?
- Are rollback copies created before significant edits?

============================================================
IMPLEMENTATION STYLE
============================================================

Use this principle:

PRESERVE -> BACK UP -> CHANGE -> TEST -> DOCUMENT

Before substantial edits:
- create a timestamped backup or git checkpoint;
- record the original state.

For Nginx changes:
- run nginx -t before reload;
- never reload a failed configuration.

For file changes:
- prefer reversible edits;
- archive instead of permanently deleting where practical.

Do not redesign blindly.

First understand how the existing site works.

Then improve it.

============================================================
DELIVERABLES
============================================================

Maintain a working assessment document while you proceed.

Create something like:

ALT-WEBSITE-ASSESSMENT.md

It should contain:

1. Current-state summary
2. Site structure
3. Major problems found
4. Security findings
5. Duplicate/redundant content
6. Consolidation recommendations
7. Changes completed
8. Files changed
9. Files archived
10. Tests performed
11. Remaining issues
12. Recommended next actions
13. Any item requiring William's approval

Also maintain a simple change log.

============================================================
PRIORITY
============================================================

Priority order:

1. Prevent accidental security exposure
2. Understand current site structure
3. Identify duplicate and unnecessary material
4. Simplify navigation/information architecture
5. Improve appearance and consistency
6. Consolidate CSS/JS/components
7. Improve operational documentation
8. Leave ALT demonstrably better than you found it

Do not spend excessive time theorizing.

Inspect the actual files and running environment.

Make safe, reversible improvements.

============================================================
COMMUNICATION RULE
============================================================

Do not repeatedly ask William for approval for routine diagnostics or reversible ALT changes covered above.

Only interrupt him when:

- a change could impact production;
- credentials are required;
- a destructive action is unavoidable;
- architecture is ambiguous enough that choosing incorrectly could break something;
- there are multiple materially different business/design directions and his preference is required.

Otherwise proceed, verify, and document.

============================================================
FINAL EXPECTATION
============================================================

When finished, give William:

- a concise executive summary;
- the most important security findings;
- what you consolidated;
- what you changed;
- what still needs attention;
- exact rollback location;
- exact files changed;
- whether ALT is currently safe and functional;
- what you recommend publishing to production later.

Remember:

ALT is the workshop.

Production stays untouched.

Inspect freely.
Change safely.
Back up first.
Verify everything.
Document what you did.

BACKUP / REPLICATION AGENT AUTHORIZATION — MIKEY

Objective:
Safely preserve and verify the FRANZA backup chain from Mikey without destructive changes.

Canonical direction:
FRANZA performs the local backup first.
Mikey pulls the already-verified FRANZA backup set over the external hostname:
    root@franza.bchicbcow.com

Use the FRANZA verified manifest as the source of truth:
    /var/lib/bcbc-backup/latest.manifest

Only proceed when the manifest reports:
    # overall=PASS

Primary Mikey backup root:
    /srv/BCBC-BACKUP

Expected first-copy structure:
    /srv/BCBC-BACKUP/FRANZA/lxc-runs/$RUN_ID

Authorized non-destructive actions:
- verify that /srv/BCBC-BACKUP is mounted;
- inspect free space;
- connect to FRANZA over SSH;
- read the verified manifest;
- derive the current run ID;
- pull only PASS-listed archive files and their .md5/.sha256 sidecars;
- preserve the FRANZA evidence file when available;
- recompute MD5 and SHA-256 on Mikey;
- write verification logs;
- re-run verification on an existing first copy;
- create a second independent local copy without overwriting the first;
- verify the second copy independently;
- stop immediately if any expected archive or checksum sidecar is missing;
- fail closed if either the first or second local copy does not verify.

Do NOT:
- prune FRANZA backups;
- delete any known-good copy;
- overwrite the only recovery copy;
- alter production networking;
- make unrelated changes;
- declare success based only on rsync exit status.

Required success state:
    FRANZA LOCAL BACKUP:      VERIFIED PASS
    MIKEY FIRST COPY:         VERIFIED PASS
    MIKEY SECOND COPY:        VERIFIED PASS
    MD5 VERIFICATION:         PASS
    SHA-256 VERIFICATION:     PASS

Document:
- run ID;
- source;
- first-copy destination;
- second-copy destination;
- archive count;
- transfer result;
- hash-verification result;
- filesystem free space;
- any warning or failure.

Never treat file existence alone as proof of a successful backup.

RUN ON FRANZA — READ-ONLY INVENTORY

for CT in 120 121 122; do
  echo
  echo "######################################################################"
  echo "CT $CT"
  echo "######################################################################"

  pct status "$CT" || continue

  pct exec "$CT" -- bash -lc '
    echo "===== HOSTNAME ====="
    hostname

    echo
    echo "===== POSSIBLE INSTALL LOCATIONS ====="
    find /opt /srv /root /home -maxdepth 4 -type d       \( -name ".git" -o -iname "*freellmapi*" -o -iname "*llmapi*" \)       2>/dev/null | sort -u

    echo
    echo "===== GIT REPOS / REMOTES ====="
    find /opt /srv /root /home -maxdepth 4 -type d -name .git 2>/dev/null |
    while read -r g; do
      d="${g%/.git}"
      echo "--- $d"
      git -C "$d" remote -v 2>/dev/null || true
      git -C "$d" branch --show-current 2>/dev/null || true
      git -C "$d" rev-parse HEAD 2>/dev/null || true
    done

    echo
    echo "===== RUNNING PROCESSES ====="
    ps aux | grep -Ei "freellmapi|uvicorn|gunicorn|node|python|bun|npm|pnpm" |
      grep -v grep || true

    echo
    echo "===== LISTENERS ====="
    ss -lntp

    echo
    echo "===== SYSTEMD ====="
    systemctl list-units --type=service --all |
      grep -Ei "freellmapi|llm|api|node|uvicorn|gunicorn" || true
  '
done

RUN ON FRANZA — CT121 ONLY — READ-ONLY PRE-UPGRADE CHECK

pct exec 121 -- bash -lc '
cd /opt/BCBC-PAIG/freellmapi || exit 1

echo "===== CURRENT GIT STATE ====="
git status --short
git status -sb
echo

echo "===== CURRENT VERSION FILES ====="
node -p "require(\"./package.json\").version" 2>/dev/null || true
node -p "require(\"./server/package.json\").version" 2>/dev/null || true
echo

echo "===== SERVICE ====="
systemctl cat freellmapi.service
echo

echo "===== NODE / NPM ====="
node --version
npm --version
echo

echo "===== PACKAGE MANAGER FILES ====="
ls -l package.json package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null || true
echo

echo "===== DATABASE / DATA FILES ====="
find /opt/BCBC-PAIG/freellmapi -maxdepth 4   \( -iname "*.db" -o -iname "*.sqlite" -o -iname "*.sqlite3" -o -iname ".env" \)   -type f -printf "%p\n" 2>/dev/null

echo
echo "===== HEALTH ====="
curl -fsS http://127.0.0.1:3001/livez || true
echo
curl -fsS http://127.0.0.1:3001/readyz || true
echo
'

You are deploying Chatto for BCBC as a controlled Proxmox LXC test.

OBJECTIVE:
Install and validate Chatto as a private self-hosted chat platform while producing enough evidence and documentation to reproduce the installation and report useful results to the Proxmox Community Scripts maintainers.

RULES:
- Do not modify LIVE/production services.
- Use an unused CT ID approved for this role.
- Before installation, record CT ID, hostname, bridge, IP, storage, CPU, RAM and disk.
- Use the Proxmox Community Scripts advanced/verbose testing mode when available.
- Preserve the complete installer output.
- Do not expose the service publicly until local function is proven.
- Do not paste secrets into documentation.
- Back up/snapshot at useful checkpoints.
- Stop before destructive or cross-environment changes.

VERIFY:
- exact Chatto version;
- systemd service name/status;
- listener and port;
- /opt/chatto_data persistence;
- /opt/chatto_data/chatto.toml;
- first operator creation;
- messaging between test users;
- persistence across service restart and container reboot;
- uploads / JetStream behavior;
- resource use;
- reverse-proxy behavior;
- TLS/public URL when configured;
- SMTP only after basic chat function is proven.

LIVEKIT:
Treat voice/video/screen sharing as a separate phase requiring a separately deployed LiveKit service. Do not mix it into the baseline Chatto validation.

REPORTING:
Maintain an install log containing:
1. architecture;
2. exact commands;
3. installer output;
4. configuration paths;
5. problems encountered;
6. fixes;
7. verification evidence;
8. rollback/snapshot;
9. final PASS/FAIL;
10. feedback suitable for the Community Scripts maintainers.

PUBLISHING:
After a successful deployment, turn the verified procedure into a OneHack/Discourse tutorial. Put the tutorial title above the post and the entire post body in ONE copyable code block.

Proceed through safe, reversible steps without repeatedly asking for permission for ordinary read-only diagnostics or validation.