Report Date: 13 October 2026
Project: TXTWRK
Subject: Original Directory API Kit, Server API Kit and Messaging API Kit compared with the consolidated Workspace, Checklist and Messaging platform.

---



TXTWRK began with three principal API kits:

1. Directory API Kit
2. Server API Kit
3. Messaging API Kit

The objective was to consolidate these technologies into one connected infrastructure that would allow users to manage files, communicate, collaborate and use their own Connected Servers for storage.

The project has progressed from individual API capabilities into a broader platform consisting of:

The most important achievement is the separation of storage, identity, permissions and collaboration records while allowing these systems to operate together.

The remaining development concerns primarily involve file-reference integrity, deletion handling, thumbnail synchronisation and complete cross-kit verification.

---





The Directory API Kit provided the foundation for managing files and folders through TXTWRK.

Its responsibilities included:



The Directory API functionality has been integrated into both Workspace and Checklist.

Workspace provides general-purpose file management.

Checklist provides a more restricted directory experience associated with a particular Checklist, its selected Connected Server and its participants.



The Directory API is no longer best understood as a completely independent user-facing feature.

It provides reusable filesystem functionality that other TXTWRK kits consume.



Status: Implemented and integrated.

Additional work remains to ensure deletion and reference synchronisation behave consistently across every consuming feature.

---





The Server API Kit established the connection between TXTWRK Central and a user's Connected Server.

Its responsibilities included:



The original verification process was designed to confirm that:

1. /TXTWRK.php was installed.
2. The server executed PHP correctly.
3. The remote agent possessed the expected secret.
4. The server identified itself correctly.
5. The server supported the required TXTWRK protocol.

Server URLs and secrets were resolved centrally rather than accepted directly from browser input.



The Connected Server model now supports multiple application features.

The general request flow is:

TXTWRK Interface
↓
TXTWRK Central API
↓
Session and Permission Validation
↓
Connected Server Selection
↓
Signed API Request
↓
Customer's /TXTWRK.php Agent
↓
Filesystem Operation
↓
Operation Result
↓
TXTWRK Central

The central API uses signed requests incorporating a timestamp, nonce and HMAC-SHA256 authentication.



The Server API provides a common infrastructure for:



Status: Core architecture implemented.

Complete security and production-readiness verification still requires end-to-end testing.

---





The Messaging API Kit was designed to provide private communication while allowing users to store media through Connected Servers.

The original concept included:



Messaging now participates in the common Connected Server model.

The reviewed central gateway supports:



Messaging identity and storage entitlement are not the same thing.

A user may be authorised to store files on a particular Connected Server without representing that server owner's Messaging identity.

This allows TXTWRK to distinguish:

Who is communicating?

from:

Which Connected Server may store the files?



Status: Shared storage authorisation implemented.

The complete Messaging attachment lifecycle still requires verification, particularly Rename, Move, Delete and database-reference consistency.

---





Workspace is TXTWRK's general-purpose file-management and working environment.

It uses the Connected Server infrastructure to perform authenticated filesystem operations.





The early Workspace implementation preserved the existing manage.php action contract.

This allowed the original browser interface to continue functioning while filesystem operations were routed through the Connected Server agent.



Workspace became aware of Checklist file relationships.

When supported Checklist files or directories are moved, the Workspace implementation can invoke central reference synchronisation.

This is important because files are no longer treated solely as independent filesystem objects.

They may also be attachments belonging to Checklist comments, replies or Threadlets.



Status: Implemented with substantial integration.

Remaining work concerns consistency after deletion, partial failures and cross-feature reference updates.

---





Checklist provides task-oriented collaboration connected to files, participants and discussions.





Each Checklist can be associated with a selected Connected Server.

The directory system operates within the Checklist's authorised context.

The later gateway implementation checks the relationship between:

This helps prevent Checklist directory access from becoming unrestricted Workspace access.



The discussion system supports attached files and richer content.

The reviewed work includes:



Threadlets extend Checklist conversations with nested discussion.

Development work included:

Threadlet attachments use an independent database structure, including threadlet_media_files.



Recent work addressed:

The revised Apply Now behaviour was reported working after testing.



Status: Broad functionality implemented and actively refined.

Some attachment lifecycle and interface interactions still require comprehensive regression testing.

---



The consolidated architecture can be represented as:

TXTWRK CENTRAL
│
├── Server Management
│ ├── Server registration
│ ├── Verification
│ ├── Stored credentials
│ └── Signed communication
│
├── Workspace Kit
│ ├── File management
│ ├── File editing
│ ├── File permissions
│ └── Checklist integration
│
├── Checklist Kit
│ ├── Items and groups
│ ├── Applications
│ ├── Comments and replies
│ ├── Threadlets
│ ├── Connected files
│ └── Member directories
│
├── Messaging Kit
│ ├── Personal identity
│ ├── Delegated identity
│ ├── Group/direct messaging
│ └── Server-backed media
│
├── Shared Authorisation
│ ├── Server ownership
│ ├── File Access
│ ├── Checklist membership
│ └── Messaging Access
│
└── Shared File Reference Management
├── Comment references
├── Reply references
└── Threadlet references
│
▼
CONNECTED SERVER
│
└── /TXTWRK.php
├── Files
├── Folders
├── Uploads
├── Downloads
├── Rename
├── Move
└── Delete

This represents the logical architecture visible in the reviewed code. It does not imply that every component has been consolidated into one physical PHP file.

---



One of the most important later developments was central attachment-reference synchronisation.



When a file or directory changes location, TXTWRK must preserve the relationship between that file and the content referencing it.



The reviewed function is:

txtwrkSyncConfirmedMoves()

It is designed to run after the Connected Server confirms a Rename or Move operation.





Table:

post_c_comment

Fields:



Table:

checklist_reply_uploads

Field:



Table:

threadlet_media_files

Fields:



Reference updates are scoped to the selected Connected Server.

This prevents an operation on one server from indiscriminately updating matching paths belonging to another server.



Original attachment:

/opensource/system/checklists/user_i/files/photo.jpg

Renamed attachment:

/opensource/system/checklists/user_i/files/new-photo.jpg

After a confirmed Rename operation, the synchronisation function can update the relevant stored references.



The reviewed implementation does not fully establish:



Status: Rename/Move synchronisation implemented for reviewed Checklist attachment structures.

Deletion and broader lifecycle consistency remain unfinished or unverified.

---



The original system already contained substantial functionality.

Later work should therefore be described primarily as consolidation, integration, extension and refinement rather than the creation of every capability from nothing.

---



The reviewed architecture includes several protection layers.













Status: Multiple security layers implemented.

A complete production security audit has not been established from the available files.

---





Established:



Developed:



Expanded:



Developed:



Refined:



Implemented:



Addressed:



Outstanding priorities:

---



These assessments refer to reviewed source code and reported testing, not measured percentages of completion.

---





Establish a consistent policy for deleting files still attached to comments, replies or Threadlets.

Recommended approach:

Block deletion while active references exist, unless an explicit attachment-removal workflow is used.



Synchronise or invalidate thumbnail_path when the corresponding media is renamed or moved.



Verify Messaging file-reference behaviour against the same lifecycle standards used for Checklist attachments.



Standardise operation responses across controllers and the Connected Server.

Avoid forcing success = true when the remote operation has failed.



Test complete workflows involving multiple kits.

Example:

1. Upload a file through Checklist.
2. Attach it to a comment.
3. Open it through Workspace.
4. Rename it.
5. Confirm the comment still opens it.
6. Move its parent directory.
7. Confirm the reference updates.
8. Attempt deletion.
9. Verify the selected deletion policy is enforced.



Preserve existing user interfaces and controls while strengthening the shared backend.

Avoid creating additional parallel APIs for operations already supported by the consolidated infrastructure.

---



The original TXTWRK architecture began with:

DIRECTORY API KIT

The developed architecture now consists of:

TXTWRK CENTRAL

The central architectural achievement is that file storage, user identity, authorisation and collaboration records can remain separate while operating through common infrastructure.

Workspace manages files.

Checklist organises work and associates files with collaborative discussions.

Messaging provides private communication and authorised media storage.

The Server API establishes trusted communication with Connected Servers.

The Directory API supplies reusable filesystem operations.

The consolidation layer connects these responsibilities.



TXTWRK has progressed substantially beyond its original three-kit foundation.

It now represents an integrated platform for connected storage, file management, collaborative Checklist work and Messaging.

The next development milestone is not another independent API Kit.

It is completing the consistency of the existing consolidated architecture across every file operation, permission boundary and attachment relationship.

The foundation is implemented. The remaining challenge is complete cross-kit reliability and verification.

---



This report is based on:

It does not constitute a live production audit, a complete line-by-line diff of every revision or confirmation that every generated replacement file has been deployed.