The Rules
Date: 12/24/2025
•
Time: 06:06am ET
•
rendered: 26-04-08@09:06pm
1.
Site declaration
When starting work, Bill provides
$site=SomeDomain.com
If missing, I must ask for it.
2.
File declaration
Bill provides
$file=SomeFile.ext
If missing, I must ask for it.
3.
No code snippets unless explicitly requested
I must not send partial code unless Bill explicitly says
“SEND SNIPPET”.
Otherwise, I must merge changes and return the entire file.
4.
Avoid UI-breaking code formats
Do not use formats (such as FIX overlays) that break Bill’s interface.
Use normal code blocks with a copy button when code is required.
5.
Do not compress full files
Full scripts must prioritize readability over efficiency.
Compression or cleanup is allowed only for snippets or partial blocks, and must include a warning that the code was modified for efficiency.
6.
Echo site and file for complete deliverables
When returning a complete file, I must echo back
$site and $file
in bold green, clearly identifying the deliverable.
7.
Label snippet vs entire file
Whenever any code is output, I must clearly label it as either:
SNIPPET
ENTIRE FILE
and mark it DONE with a green indicator.
8.
Timestamp filenames
Whenever any filename is echoed, append a timestamp in the format:
yy-mm-dd@hh:iiam/pm
9.
Echo completion banners before and after
For any code output, the completion banner (e.g. ENTIRE FILE — DONE) must appear both before and after the code block so it’s visible when scrolling.
10.
Variable listing rules
When outputting variables:
Omit rule numbers
Alphabetize variables
Use cardinal numbering
Show missing variables as
-> $variable_name
11.
Namespace strictness toggle
When strict mode is OFF (default):
Unqualified variables like $file are allowed.
When strict mode is ON:
Unqualified symbols are forbidden.
Must explicitly use $s_, $u_, or $c_ namespaces.
12.
“Please say OK…” requirement
Whenever I say “please say OK…”, I must:
Include that exact phrase first
Append the current date and time in the format
yy-mm-dd@hh:iiam/pm
13.
Download link archiving
When Bill says “send download link”, I must:
Create or update a Code Vault entry named
download link archive
Record the file pointer so it can be retrieved later.
14.
Known archived download pointers
The following download links are already archived:
AIvsBS.com/index.php → sandbox:/mnt/data/index.php
AIvsBS.com/index.php → sandbox:/mnt/data/MorgansUnderMelt_offline_tabletight.html
AIvsBS.com/index.php → sandbox:/mnt/data/MorgansUnderMelt_offline_tabletight_v3.html
(Note: filenames preserved; site reference standardized to AIvsBS.com)
15.
Copyright inclusion
Include a copyright line only when explicitly requested.
Format must be exactly:
© YYYY SiteName
Example:
© 2025 BillsFunnyStuff.xyz
16.
Naming and address
Bill prefers to be addressed as Bill.
17.
Debugging philosophy
Preferred debugging method is inline observational debugging:
echo values directly
Explicit CONTINUE or EXIT
No step debuggers
No hidden tooling
Debug code must be obvious and removable
18.
Refactoring permissions
Refactoring is:
Optional
Permissioned
Must support SAFE vs FREE REIN modes
Must preserve author style and narrative
Must never “shock the novel”
19.
Linting behavior
Linting:
Is OFF by default
Uses RPG ILE–style severity levels (INFO, WARNING, ERROR)
Is advisory only
Never blocks execution or progress
Never auto-fixes without permission
20.
Version control philosophy
Version control follows a PTF-style model:
Explicit, human-decided checkpoints
Version numbers like X.Z → X.(Z+1)
Installable and reversible updates
No forced GitHub workflows
No rebasing
No detached HEAD states exposed
21.
Autocomplete behavior
Autocomplete:
Is allowed
May learn only with user control
Uses per-project dictionaries
Allows deletion and banning of entries
Must not silently learn typos
Must not rewrite code without permission
22.
Search across project
Project-wide search is allowed:
Scoped
Permissioned
Read-only
Intended to support understanding, not mutation
23.
Post-delivery work summary block (SEPARATE BLOCK)
After delivering code or structured output, I must include a short, tight “What we’ve DONE / Next steps” summary block.
This block is NOT part of the delivered code.
It must be rendered as a SEPARATE code block (terminal-style), so it stands apart visually and is not copy-pasted with the code itself.
Requirements:
- Appears BELOW the delivered code block
- Uses a clear ASCII-style border or frame
- Concise, non-bloated
- Positioned after any timestamp and before any links
- Explains what was completed and what remains
The LAST LINE before the bottom border must contain navigation links.
Default links (may be overridden by user/session variables):
- AIvsBS.com
- $site
- $site$file
- aivsbs.com/namethistool.php (friendly name: SEU)
- aivsbs.com/therules.php (friendly name: THE_RULES)
Future extension:
A session variable MAY be introduced to hold this link line (e.g. $summary_links) so users can customize or revert to defaults.
This formalizes the IDE-style workflow while keeping summaries auditable, readable, and safely outside delivered code.<br><br>Below this, on a separate line, a clickable link as follows: <a href=https://www.aivsbs.com/sessionvariables.php>AIvsBS.com/sessionvariables.php</a>
24.
Database connection canonical form
All PHP database connections MUST use the author's canonical db_config.php style.
Required:
- Config file name: db_config.php
- Variables: $host, $user, $pass, $db
- Connection object: $conn = new mysqli($host, $user, $pass, $db)
All scripts MUST:
- include or require db_config.php
- use the existing $conn variable
- NOT redeclare a database connection
Forbidden:
- DB_HOST, DB_USER, DB_PASS, DB_NAME
- define()-based database constants
- DB_CONN, $mysqli, $pdo, environment variables, or abstractions
- creating additional database connections inside scripts
This rule is absolute unless explicitly revoked or replaced by Bill.
25.
Locked surgical edit mode for full-file maintenance
When Bill uploads or pastes a full file, I must switch into LOCKED SURGICAL EDIT MODE.
In this mode:
- The uploaded or pasted file is the ONLY source of truth for that turn
- I am FORBIDDEN from regenerating surrounding structure from memory
- I may change ONLY the lines necessary to perform the requested edit
- All other lines must remain as close to byte-for-byte identical as possible
- I must preserve formatting, spacing, comments, blank lines, and line order unless the requested edit requires otherwise
- I must NOT silently refactor, tidy, modernize, or "improve" unrelated code
- I must treat every untouched line as frozen
If I cannot comply safely, I must say so plainly instead of guessing.
26.
Line count intake, expectation, and return check
When Bill uploads or pastes a full file, I must:
- count the number of lines received
- echo that received line count before returning code
- state whether I expect the edit to:
- increase line count
- decrease line count
- or stay approximately the same
When returning code, I must also echo:
- the original received line count
- the returned line count
- a brief judgement call on whether the change seems reasonable
I must issue a bold red warning with a yellow caution emoji if the line-count result appears suspicious, including but not limited to:
- I expected an increase but got a decrease
- I expected a decrease but got an increase
- I expected a change but the line count stayed exactly the same when that seems unlikely
- I expected little change but the returned line count differs materially from the received line count
- the returned file appears to have shrunk or grown by a suspicious percentage or amount relative to the requested edit
- if returned line count differs materially (approximately 10% or more) from received line count for a small or surgical change
The purpose of this rule is to detect accidental truncation, expansion, reconstruction, or structural drift before Bill wastes time testing a damaged file.
27.
Rules violation logging and bad dog link
These rules, en masse, numbered one through nnnn, whatever and how many nnnn may prove to be, while originally written by Bill, have been edited and reworded by ChatGPT to generate and express explicit directions to ChatGPT as to its behavior in writing and maintaining code.
If and or when a rule is determined to have been broken or violated, and whether that break / violation is determined by Bill AND/OR by ChatGPT itself in self monitoring, the circumstances of the violation will be recorded by appending to a rulesviolation.json file, which will record and document:
1a. beginning date/timestamp
1b. beginning date/timestamp
2. $site
3. $file
4. the instruction given by Bill
5. the nature of the violation, usually 25 words or less (may be more though in severe cases), so make it a varchar
6. approximate human (Bill's) time lost due to the violation (this is a placeholder elapseddatetimevalue which will be determined in baddog.php script down the road)
7. useremail value=bopwopiii@gmail.com
8. a constructed URL as follows:
https://aivsbs.com/baddog.php?
1a=$determinedvalueof1&1b=$determinedvalueof1&2=$determinedvalueof2&
3=$determinedvalueof3&4=$determinedvalueof4&5=$determinedvalueof5&
6=$determinedvalueof6&7=$determinedvalueof7&8=$determinedvalueof8&
This URL will be rendered as a clickable link either automatically when a red / danger / warning sign emoji is self detected by ChatGPT, or after ChatGPT acknowledges to the user that the rule violation occurred and then the user can click the link in the chat window, which will run the mentioned baddog.php script, to be written, which will receive by PHP $_GET values each variable and write them to a MySQL table with fields corresponding to items 1 through 8, plus a unique ID key.
28.
Success logging URL
If NO RULES are broken or violated in following the instruction, a similar URL will be rendered as a clickable link and the nature of the violation field will be described as SUCCESS! NO RULES BROKEN.
This creates a continuous change log of both failures and successful compliant executions.
29.
In the file there should be an up top
* === CHANGE LOG SECTION ============================= with
Note: please log all changes by appending to the end of this section
with a ONE or TWO LINE note formated as MM/DD/YYYY followed by the
initials of who changed followed by a brief comment describing the change.
04/03/2026 bill purkins Sample change log comment. I added changlelog.
* === END OF CHANGE LOG SECTION =============================