Skip to content

PointSav Documentation

The engineering library for the PointSav platform — operating systems and services for regulated businesses that own their data, their AI, and their record-keeping outright. Where the monorepo holds the code, this wiki holds the reasoning: architecture, services, security, and the governance commitments that bind future development.

PointSav Digital Systems

Revision as of · 7d712980

Historical revision — this record as it stood on 5 September 2026, not the current version. View the current record →

How to read and write Totebox archives

A Totebox Archive is a scoped working environment: a git repository cloned from an upstream source, configured with session rules, inbox and outbox mailboxes, and a drafts pipeline. Reading an archive means understanding its current state — the inbox, active work, and session context. Writing to an archive means committing to its git history using the staging-tier commit flow. This guide covers both operations.

For the session model that governs archive access, see Totebox session and Totebox orchestration as the development environment.

Prerequisites

Purpose

Read a Totebox Archive's current state at session start, write changes through the staging-tier commit flow, stage editorial drafts correctly, and communicate across archives through the mailbox protocol rather than by editing another session's state files.

Procedure

  1. Read an archive's state at session start, in this order:

    • Open .agent/inbox.md and review pending messages — these represent work or information relayed from other sessions.
    • Open .agent/session-start.md if present — it contains orientation notes from the last session that closed in this archive.
    • Open .agent/memory/session-context.md for a rolling 5-session summary including carry-forward items and operator preferences.
    • Run git status to see any uncommitted changes. If files are staged or modified without a commit, read them before starting new work.
    • Read NEXT.md — the archive's open items queue; what is in progress and what is blocked.

  2. Write to the archive using the staging-tier flow. Do not use git commit directly — use the commit-as-next.sh helper, which sets the correct author identity and signs the commit:

    • Make your changes.
    • Stage specific files: git add <file> <file> — never git add . or git add -A.
    • Commit: ~/Foundry/bin/commit-as-next.sh "<message>".
    • Verify: git status should show a clean tree.

    Commits in an archive stay on the local feature branch until Stage 6 promotion by the Command Session.

  3. Stage editorial drafts for handoff, if applicable. If your work produces an article draft, stage it to .agent/drafts-outbound/ with the correct foundry-draft-v1 frontmatter before closing the session. Do not commit draft content directly to the wiki repos from an archive — the draft flows through the editorial pipeline first. A staged draft carries frontmatter with artifact, schema: foundry-draft-v1, status: staged, route-to:, plus body content suitable for the destination wiki article.

  4. Communicate across archives via the mailbox, never by editing another session's state files. Messages arrive at .agent/inbox.md from other sessions and are read at session start; new outbound messages are prepended to .agent/outbox.md, which the Command Session sweeps at intervals. Write to another archive's inbox only via the Command Session or an approved MCP tool (send_mailbox_message) — never edit another session's inbox directly.

Expected outcome

The archive's state (inbox, session context, git status, NEXT.md) is understood before new work starts; any commits land through commit-as-next.sh with a clean working tree afterward; any draft output is staged to .agent/drafts-outbound/ rather than committed directly to a wiki repo.

Verification

git status shows a clean tree after each commit. A staged draft's frontmatter validates against the foundry-draft-v1 schema. No direct edits appear in another session's .agent/inbox.md or .agent/outbox.md.

Rollback

An uncommitted change can be discarded with git checkout -- <file> or git restore <file> before staging. A committed change on the local feature branch has not yet promoted to canonical (Stage 6 is a separate, later step), so reverting it is a normal local git operation, not a production rollback.

Next steps

See also

Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is currently a trade name of Woodfine Capital Projects Inc. ("Woodfine"), planned to become a wholly-owned Woodfine subsidiary upon incorporation. PointSav does not itself offer, sell, or solicit any security. Any securities offering associated with Woodfine's real-property direct-hold solutions is made exclusively by Woodfine, and only by means of the applicable Private Placement Memorandum.

No investment advice. This wiki's content is provided for engineering, operational, research, and development purposes. Nothing on this wiki constitutes investment advice or a solicitation to invest in any Woodfine partnership or direct-hold solution.

Intellectual property. The PointSav name, trade name, wordmark, and marks, together with all current and future PointSav- and Totebox-branded products, services, and offerings — and the software, source code, documentation, design system, and all related materials — are proprietary to Woodfine and its affiliates, except for components identified as open source. No rights are granted except as expressly set out in a written license or agreement. The full trademark notice appears in the footer of every page on this site.

Open source components. Portions of the platform are made available under permissive open-source licenses identified in the accompanying repository. Use of those components is governed by their respective license terms.

No warranty; informational use. Content on this wiki is provided for general informational purposes only and does not constitute a representation, warranty, or commitment with respect to product functionality, availability, pricing, or roadmap. Some articles describe planned or intended features, capabilities, and milestones — language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Confidentiality. Where an article describes an operational or deployment detail that is not intended for public disclosure, that article is not published on this wiki. Content here is general-purpose engineering documentation, not customer-specific configuration.

Jurisdiction. Woodfine Capital Projects Inc. is organized in British Columbia, Canada. References to the Sovereign Data Foundation on this wiki describe a planned or intended initiative only, not a current equity holder or active governance body.

Changes to this notice. PointSav may update this notice from time to time; the version posted on this page governs.

Not a filing system. This wiki is not a securities filing system, an electronic disclosure repository, or a substitute for SEDAR+ or any other regulatory filing system. Formal securities filings are made through the applicable regulatory filing system, not through this wiki.

Full disclaimer. This notice supplements, and does not replace, the full Disclaimers article. In the event of any conflict, the full Disclaimers article governs.

Read the full disclaimer →