A practical system for keeping websites, servers, email, CRM, automation, and AI-assisted work understandable when the work spans several chats, tools, and months.
The problem we ran into
RiverdalePro’s website and help desk were built in different work sessions. The current session knew how to reach the help-desk server, while the original website access details lived in an older project. Nothing was actually lost, but the context was fragmented. Before changing the website, we had to find the earlier connection, determine what kind of access it provided, and test it safely.
The test revealed an important distinction: the website host accepted secure file transfers over SSH, but did not permit an interactive command shell. An earlier note that simply said “SSH access” was technically true and operationally incomplete. That one missing detail could have caused needless troubleshooting or an unsafe workaround.
The fix was not a better prompt. It was a better system of record.
Chat history is context, not your source of truth
AI project memory is useful, but it should not be the only place where operational facts live. OpenAI’s documentation explains that project memory uses the conversations and files available to a project, and that project-only memory cannot refer to conversations outside that project. Its memory FAQ also notes that memory does not retain every detail. That makes projects excellent working spaces, but not substitutes for an explicit handoff record.
Your source of truth should be readable without reconstructing a conversation. A new person—or a new AI session—should be able to open one folder, understand the system, verify the current state, and identify the next safe action.
The continuity stack
README.md
The front door: what the project is, where to start, and what must never be stored there.
SYSTEM-MAP.md
Domains, services, integrations, data flow, ownership, and boundaries between systems.
OPERATIONS.md
How to connect, inspect, back up, deploy, roll back, and verify—without including passwords.
TASKS.md
Active work, waiting items, future ideas, and completed work with dates.
DECISIONS.md
Important choices, the reason for each choice, and the alternatives that were rejected.
CHANGELOG.md
What changed, when it changed, where it changed, and how it was verified.
HANDOFF.md
The latest verified state, known risks, and the exact next action for the next session.
Version-controlled source
The website theme, configuration examples, and public-guide source—with meaningful commits.
A sanitized RiverdalePro system map
public website
├── managed WordPress host
│ ├── custom theme
│ ├── public guides
│ └── secure file-transfer access
│
├── helpdesk subdomain
│ └── Frappe Helpdesk on a separate server
│
└── Microsoft 365
├── shared public support mailbox
└── licensed identity used for OAuth
customer email
↓
shared mailbox
↓ authenticated mail connection
help-desk ticket
↓ authenticated outgoing mail
reply from the public support address
This map is useful because it records the boundaries. The website and help desk are on different servers. The public mailbox and the licensed sign-in identity serve different purposes. Website content and theme files are different kinds of state. A change to one part should never assume access to another.
Use memorable connection aliases
OpenSSH supports host-specific settings in a user configuration file. Give each system a plain-language alias and specify its approved identity file there. This reduces typing errors and makes procedures readable:
Host company-website
HostName example-host.invalid
User website-account
IdentityFile C:/Users/you/.ssh/company_website_key
Host company-helpdesk
HostName 192.0.2.10
User operations-user
IdentityFile C:/Users/you/.ssh/company_helpdesk_key
The runbook can safely say “connect to company-helpdesk” without publishing a private key or password. Test each alias with a harmless read-only action and record what the account actually permits: shell access, file transfer, or both.
Keep secrets out of the project
Document the owner and approved storage location of a credential, not the credential itself. Private keys, passwords, OAuth secrets, recovery codes, database exports, and customer data should not be copied into task notes or version control. OWASP’s secrets-management guidance recommends centralizing and controlling secrets rather than scattering plaintext credentials through source and configuration.
Unsafe: copying the client secret into the runbook, chat, or repository.
The operating routine
At the start of a work session
- Open the permanent project—not a random downloads folder.
- Read
HANDOFF.md, then checkTASKS.md. - Confirm the system boundary in
SYSTEM-MAP.md. - Run read-only checks before making changes.
- Back up the exact file or record you intend to change.
During the work
- Change the smallest practical scope.
- Keep editable source in version control; Git records snapshots and the history between them.
- Record decisions that would otherwise need to be rediscovered.
- Test the user-facing result and the rollback path.
Before ending the session
- Update the change log with what actually happened.
- Move completed tasks and record any new risk.
- Replace the handoff note with the latest verified state and one clear next action.
- Scan the project for credentials or customer data.
- Commit the documentation and source together.
Copyable starter templates
Project operations template
# Project Operations ## Purpose [What this system does and who owns it] ## Environments - Production: [public URL] - Staging: [URL or “none”] ## Access - Connection alias: [safe alias] - Credential owner/location: [reference only; no secret] - Access type: [shell, SFTP, admin UI, API] ## Safe change procedure 1. Inspect current state. 2. Back up the exact target. 3. Make the smallest change. 4. Verify the public result. 5. Record the change and rollback. ## Backup and rollback [Schedule, location, retention, last restore test] ## Known risks [Unverified assumptions and active risks]
Session handoff template
# Current Handoff Updated: [date and timezone] ## Verified state - [Fact that was tested] ## Changed this session - [Change and verification] ## Known risks - [Risk, owner, and status] ## Next action [One concrete action] ## Closeout - [ ] Tasks updated - [ ] Decisions/change log updated - [ ] Secrets scan clean - [ ] Source committed
System map template
# System Map Last verified: [date] ## Components - [Domain/service] — [purpose, owner, environment] ## Data flow [source] → [integration] → [destination] ## Boundaries - [Systems that are separate] - [Identity versus public address] - [Content state versus source-code state] ## Dependencies - [External service and failure impact]
If your continuity is already fragmented
- Find: search old project folders, task histories, deployment notes, and local connection configurations. Treat recovered notes as clues, not proof.
- Test: verify each connection with a non-destructive action. Confirm the hostname, account, access type, production path, backup state, and public URL.
- Consolidate: build one permanent project, copy in the current source, and write the seven continuity files.
- Secure: move secrets to approved storage, rotate temporary credentials, and remove abandoned copies.
- Publish: turn the sanitized, tested procedure into a guide only after the internal process works.
What “tested” should mean
| Claim | Minimum evidence |
|---|---|
| Connection works | A read-only login or file listing using the documented alias |
| Backup works | A recent backup exists and its location and schedule are known |
| Restore works | A documented restore test—not merely a successful backup job |
| Deployment works | The intended file or record changed and the public result was verified |
| Handoff works | A new session can identify the current state and next action without reconstructing old chats |
RiverdalePro’s continuity system passed the connection, deployment-source, public-URL, and handoff checks. The help-desk server’s local backup schedule was also verified. Off-server retention and a full restore test remain open risks, so we do not claim those are complete.
References
- OpenAI: Projects in ChatGPT
- OpenAI: Memory FAQ
- OpenBSD: ssh_config manual
- Git: git-init documentation
- OWASP: Secrets Management Cheat Sheet
Want help turning scattered projects into an operating system?
RiverdalePro helps small businesses document, connect, and verify the systems behind their websites, lead flow, support, and automation.