Skip to main content

Target Directory Map

Purpose

This document defines the proposed target state for the Aptlantis workspace. It is not a migration log and does not authorize moves by itself.

Current state is recorded in Workspace Inventory.

Target Roots

PathRoleGoverning standardRequired manifest
D:\.agentsDrive-level agent directory and agent-facing workspace servicesWGS / ATS.agents.manifest.toml
D:\010-CITY-HALLCanonical standards, rules, frameworks, referencesWGS / SFDS010-CITY-HALL.manifest.toml
D:\015-DPWPublic works and shared servicesWGS015-DPW.manifest.toml
D:\020-LIBRARYDocument nexusWGS020-LIBRARY.manifest.toml
D:\030-ZONINGInitial project scaffolding area for required docsWGS / PPS030-ZONING.manifest.toml
D:\100-DRSDesktop application projectsDRS100-DRS.manifest.toml
D:\200-CTSCommand-line tools and automation utilitiesCTS200-CTS.manifest.toml
D:\300-WDSWebsites and web applicationsWDS300-WDS.manifest.toml
D:\400-DDSDatasets, corpora, and training data projectsDDS400-DDS.manifest.toml
D:\500-SFDSStandards and framework projectsSFDS500-SFDS.manifest.toml
D:\960-QBQuickBASIC / QB64 ecosystemWGS960-QB.manifest.toml
D:\970-EVALSEvaluation records, local benchmark results, analysis outputsAAS / WGS970-EVALS.manifest.toml
D:\980-DATAGeneral data storage and governed data assetsDDS / WGS980-DATA.manifest.toml
D:\990-TESTSWorkspace-level tests and validation fixturesWGS990-TESTS.manifest.toml

Directory Numbering Intent

RangeMeaning
000-099Governance, references, setup, and staging
100-199Desktop release projects
200-299Command tools and automation
300-399Websites and web applications
400-499Datasets and corpora
500-599Standards and framework projects
900-999Legacy, evaluation, data, tests, and special-purpose roots

Implemented Category Numbering

RootCategoryPurpose
D:\100-DRS110-CRYPTOCryptography, trust, and security-sensitive desktop apps.
D:\100-DRS120-STORAGEStorage, vault, and local data desktop apps.
D:\100-DRS130-ARCHIVALArchival desktop apps and plugins.
D:\100-DRS140-TAURITauri/webview desktop applications.
D:\100-DRS150-QBQB-related desktop utility packages.
D:\100-DRS160-UTILITIESGeneral desktop utilities.
D:\200-CTS210-CONVERSIONConversion and transformation command tools.
D:\200-CTS220-APIAPI acquisition and reference tooling.
D:\200-CTS230-HASHINGHashing and integrity command tools.
D:\200-CTS240-DATA-PIPELINESDataset and training pipeline tools.
D:\200-CTS250-DOCS-SCRIPTINGDocumentation, project analysis, and script-writing tools.
D:\200-CTS260-LLMLLM-related command tooling.
D:\200-CTS270-MEDIAMedia and asset generation tools.
D:\300-WDS310-aptlantis.netCanonical aptlantis.net website project.
D:\300-WDS320-aptlantis.studioCanonical aptlantis.studio website project.
D:\300-WDS330-TEMPLATEWeb templates and starters.
D:\300-WDS340-SITESAdditional website projects.
D:\300-WDS390-SERVERWebsite server infrastructure.
D:\980-DATA981-CRATESIOCrates.io data assets.
D:\980-DATA982-NODEJSNode.js data assets.
D:\980-DATA983-WINGETWinget data assets.

Standard Project Layout

Every governed project should eventually have:

ProjectRoot\
├─ ProjectName.manifest.toml
├─ PROJECT.md or proposal document
├─ README.md
├─ docs\
├─ templates\ # if the project defines reusable docs or structures
├─ examples\ # if the project defines a standard or reusable pattern
└─ tests\ # if validation is executable

Project-specific standards can add required folders, but WGS requires an entity-named manifest and enough human-readable context for future recovery. The reusable project.manifest.toml file remains the generic v2.4 template/schema default.

Standard / Framework Layout

Standards governed by SFDS should move toward:

StandardRoot\
├─ StandardName.manifest.toml
├─ README.md
├─ [Standard Name].md
├─ schema\
├─ templates\
├─ examples\
├─ validators\
├─ adoption-guide.md
└─ CHANGELOG.md

Migration Rule

No current root should be renamed, moved, or merged only because this target map exists. Every structural change requires:

  • Current-state inventory entry.
  • Target path.
  • Reason for the change.
  • Safety classification.
  • Manual approval if data could be orphaned, duplicated, or made harder to recover.

Implementation Status

As of 2026-06-11, the primary target roots use entity-named manifest records. The live workspace manifest uses Aptlantis Entity Manifest v2.4 so directories and projects are both first-class manifest entities.

Completed structural migrations:

  • D:\LIBRARY -> D:\020-LIBRARY
  • D:\970-DATA -> D:\980-DATA
  • D:\980-EVALS -> D:\970-EVALS
  • created D:\030-ZONING
  • restored legacy root manifests to canonical entity-named manifest files
  • added directory manifests to top-level service/cache roots
  • categorized DRS, CTS, WDS, and DATA child roots into numbered groups

:::note Superseded numbering This numbered-root target map (010-CITY-HALL, 100-DRS, 200-CTS, etc.) reflects an earlier planning stage. The current live workspace (documented in Workspace Inventory and the Workspace Root Snapshot) uses un-numbered top-level roots (D:\CTS, D:\DRS, D:\WDS, D:\DATA, D:\.city_hall, and hidden foundation directories .dpw, .library, .sonar). This document is preserved as historical planning evidence per the WGS drift-preservation rule, not as the current physical layout. :::