Document ID : DARX-OPS-ADMIN-MANUAL-001 Title : Daralbeida Platform — Administrator User Manual Version : 1.0 Status : ACTIVE Date Created : 2026-06-03 Prepared by : PYB / Daralbeida Style : BPGP Department : OPS Classification: Internal KB Category : WEB-FRONTEND Filename : DARX_OPS_ADMIN_MANUAL_20260603.txt Related Docs : DARX-TECH-ARCH-B-001 OUTLINE -------------------------------------------------------------------------------- 1. Purpose and Scope 2. Opening the Site Manager 3. Adding a Document 4. Editing Document Metadata 5. Skin Dashboard 5.1 Opening the Dashboard 5.2 Editing a Value 5.3 Cascade Reminder 5.4 Resetting a Value 6. Creating a New Entity 6.1 Decide the Codes 6.2 Stamp the Folders 6.3 Write the Entity Skin 6.4 Create the Entity Homepage 6.5 Seed the Skin Values 6.6 Assign Documents to the New Entity 6.7 First Visit and Verification 6.8 Deploy to Production 7. Adding a Section 8. Image Placement 9. Deploying to Production 10. Troubleshooting 11. Acronyms 12. Glossary DOCUMENT CONTROL -------------------------------------------------------------------------------- ================================================================================ 1. PURPOSE AND SCOPE ================================================================================ This manual is the operating guide for the administrator of the Daralbeida multi-entity web platform. It covers everyday tasks (adding documents, editing their metadata, tweaking skin values) and one-off tasks (creating a new entity site, deploying to production). The reader is the platform administrator. The technical architecture sits in DARX-TECH-ARCH-B-001; this manual references that document where it matters but does not duplicate its content. ================================================================================ 2. OPENING THE SITE MANAGER ================================================================================ The site manager lives at the master path: /_devt/__darmaster/12/ (in development) /_prod/__darmaster/12/ (in production) The manager has two tabs: Documents edit each file's registry row (entity, section, status, …) Skins /_devt/__darmaster/12/skins.php — adjust per-entity visual values You open the manager in any browser on the local server. There is no login; access control sits at the server level. ================================================================================ 3. ADDING A DOCUMENT ================================================================================ The flow is exactly three steps. Step 1. NAME THE FILE per the project naming convention: ENTITY_CATEGORY_DESCRIPTOR_YYYYMMDD.ext Underscores only. The date is today's creation date (never copied from an older file). Examples: DARH_OPS_MILL_INSPECTION_SOP_20260603.txt DARX_TECH_CAROUSEL_CHANGELOG_20260527.txt DARM_KB_HARVEST_CALENDAR_2026_20260603.html Step 2. DROP THE FILE into one of the master trunks: .txt → /_devt/__darmaster/11/0101/txt/ .html → /_devt/__darmaster/11/0102/html/ The scanner picks the file up on the next page load and auto- registers it in /_devt/__darmaster/api/doc_status.csv with default values: status = 0 (private), entity inferred from the filename token, section inferred from the filename-to-section map. Step 3. PUBLISH IT in the manager. Open /__darmaster/12/, find the row, set status = 1, set the section if the default is wrong, and confirm the entity assignment. Save. The document now appears on every entity site that the entity column allows, under the section number it was assigned to. ================================================================================ 4. EDITING DOCUMENT METADATA ================================================================================ Each row in /_devt/__darmaster/api/doc_status.csv has these editable columns: status 1 = public (shown on portals), 0 = private (hidden everywhere) entity the entity code, or a comma-list, or "shared": DARH → appears only on /__darh/ DARH,DARM → appears on /__darh/ and /__darm/ shared → appears on every entity site section the section number where the doc appears (01..07) dept the department/function tag (TECH, OPS, STDS, KB, …) title override of the title parsed from the file (rarely needed) Editing a row is non-destructive — the file on disk is untouched. To move a document from /__darh/02/ to /__darm/03/, change entity from "DARH" to "DARM" and section from "02" to "03" in its row. The file does not move on disk. A common gotcha: if a freshly added file appears on /07/ when you expected /02/, its filename CATEGORY is not in the filename-to-section map. Set the section explicitly in the registry row; the map is only a default. ================================================================================ 5. SKIN DASHBOARD ================================================================================ The skin dashboard is the only place per-entity and per-section visual values are edited. Editing CSS files directly is reserved for structural changes; the dashboard handles palette, fonts, and density. 5.1 OPENING THE DASHBOARD /_devt/__darmaster/12/skins.php The page lists every scope (global, each entity, each section) along the left and the variables for that scope along the right. Selecting a scope loads its current values into form controls. 5.2 EDITING A VALUE Each variable has the appropriate control: Colour a colour picker with a HEX text field for precise input Font a dropdown of platform fonts, plus a "custom" text field Compactness a three-way segmented control: compact · normal · spacious Density a three-way segmented control: tight · normal · loose Shadow a three-way segmented control: none · subtle · strong Letter sp. a number input in em units Saving writes the value back to /_devt/__darmaster/api/skin_values.csv and bumps the shared cache token, so every entity site picks up the change on its next request. A live preview frame on the right of the dashboard reloads with the new value applied, scoped to the current (entity, section) combination. Use the entity and section selectors at the top of the preview to test the value's effect on any combination before saving. 5.3 CASCADE REMINDER Values are layered global → entity → section. A value set at a higher scope wins. So: - Set brand-primary at the entity scope to colour DARH everywhere. - Set a different brand-primary at the section-02 scope to make section 02 stand out on DARH while leaving every other section of DARH alone. If you want a value to apply to every entity, set it at the global scope. Override per entity only where needed. 5.4 RESETTING A VALUE Each variable row has a small "reset" control. Resetting at the section scope falls back to the entity value; resetting at the entity scope falls back to the global value; resetting a global value falls back to whatever default the entity skin file or base/tokens.css defines. This means you cannot break the platform by clearing values — there is always a deterministic fallback. ================================================================================ 6. CREATING A NEW ENTITY ================================================================================ This is the canonical task. The platform is designed so that adding an entity is fast, repeatable, and zero-prose: you stamp folders, write one skin file, and add a row or two to the CSVs. Code changes are not required. The example uses a fictional entity "DARN" (Daralbeida Nuts). Substitute your actual codes throughout. 6.1 DECIDE THE CODES - Choose the ENTITY token used in document filenames (e.g. DARN). Convention: four uppercase characters, starting with DAR. - Choose the entity folder name (e.g. __darn). Convention: lowercase of the entity code with two leading underscores. - Choose the entity's human-readable name (e.g. Daralbeida Nuts). Record the mapping anywhere you keep your project notes; this is the only place the three identifiers need to be agreed on by humans. 6.2 STAMP THE FOLDERS From the dev mirror's web root, create the entity folder shape: mkdir -p /_devt/__darn/{01,02,03,04,05,06,07} mkdir -p /_devt/__darn/img/{logo,favicon,hero,kc,marketing} That is the entire required directory structure. No api/, no css/, no 12/, no 11/. 6.3 WRITE THE ENTITY SKIN The skin file lives in master: /_devt/__darmaster/css/skins/entity-darn.css Start by copying entity-darh.css as a template. Change the palette tokens the file declares, rename any DARH-specific class scopes, and save. The skin's job is to give the entity its visual identity — anything purely operator-tunable should be left as CSS custom properties so the dashboard can drive it. 6.4 CREATE THE ENTITY HOMEPAGE Two files do most of the work. a) /_devt/__darn/_entity.php — defines the entity constant and bootstraps the master helpers. Copy verbatim from another entity, change the ENTITY constant value: / - the entity's wordmark, favicon set, founder portraits, hero photography, keycard photography → /_devt/__/img// When in doubt, err toward master. ================================================================================ 9. DEPLOYING TO PRODUCTION ================================================================================ Production is /_prod/, a mirror of /_devt/. The deploy is a directory sync; no code generation step is required. The conventional sequence: Step 1. Verify in dev. Click through every entity site that has changes, walk through each section, confirm document lists and skin look correct. Step 2. Bump cache tokens. If any CSS, JS, or PHP files changed, bump their ?v= tokens in index.php of each affected entity. The dashboard does this automatically for skin saves. Step 3. Sync the changed files: rsync -av /_devt/__darmaster/ /_prod/__darmaster/ rsync -av /_devt/__darh/ /_prod/__darh/ # repeat for any entity that changed Or stage the diff and copy manually if the change set is small. Step 4. Smoke-test in prod. Open each affected entity's homepage and one section portal. Confirm document lists are populated. Step 5. If anything is wrong, roll back by restoring the previous /_prod/ snapshot. The /_devt/ tree is your working copy and should already have the correct prior state in /_revert/. ================================================================================ 10. TROUBLESHOOTING ================================================================================ Symptom: A document appears on /07/ (Appendix) when I expected another section. Cause: Its registry row has no section assigned, so the system fell back to its filename-to-section map, which routed it to 07 by default. Fix: Set the section column in the document's registry row explicitly. Symptom: A document does not appear on any portal. Cause: Status is 0 (private), or the entity column does not include the current entity (and is not "shared"), or no row exists in the registry yet. Fix: Open the row; set status to 1; confirm the entity column matches the entity site you are viewing. Symptom: The skin dashboard shows the new entity but the entity site is not picking up the values. Cause: The cache token did not bump on save, or the entity homepage is using a hardcoded ?v= older than the bump. Fix: Save once more in the dashboard, or manually bump the cache token in the entity's index.php. Symptom: A new entity site renders unstyled. Cause: /_devt/__/_entity.php is missing or does not define the ENTITY constant. Fix: Create _entity.php with the ENTITY constant set, requiring the master helpers — see Section 6.4.a. Symptom: Images return 404 on the entity site but resolve fine in /__darmaster/. Cause: The src is relative; the page's rebases it to the entity folder instead of master. Fix: Use darx_img() for master images and darx_img_entity() for entity images. Both emit absolute URLs that resolve correctly under any . Symptom: The shared top nav looks different on one entity than the others. Cause: That entity's skin file is overriding nav module CSS at higher specificity. The nav module is sitewide; per-entity overrides break the convention. Fix: Remove the nav rules from the entity skin and rely on the shared module. If a specific nav tweak is required for an entity, propose it as a global change first. ================================================================================ 11. ACRONYMS ================================================================================ The following acronyms appear in this document: Acronym Expansion ──────── ──────────────────────────────────────────── BPGP Bullet-Proof Ground-Plane CSS Cascading Style Sheets CSV Comma-Separated Values DARH Daralbeida Holdings DARM Daralbeida Mill DARN Daralbeida Nuts (example entity) DARX Daralbeida-X HEX Hexadecimal (colour notation) PHP PHP: Hypertext Preprocessor SOP Standard Operating Procedure ================================================================================ 12. GLOSSARY ================================================================================ Key terms used in this document: Term Definition ───────────────── ────────────────────────────────────────────────────── Dashboard The skin values editor at /__darmaster/12/skins.php. Entity site A standalone-feeling website under /__darh/, /__darx/, … Master The cockpit at /__darmaster/; single source of truth. Mirror A deployment copy: /_devt/ (dev), /_prod/ (prod). Portal A section page (01..07) that lists documents. Registry A CSV read by code, edited only via the UI. Section A numbered domain (01..07): Company, Market, etc. Shim A thin entity-side file that defers to master. Skin A CSS layer giving an entity or section its identity. Trunk A flat directory: the document or image store. DOCUMENT CONTROL Document ID : DARX-OPS-ADMIN-MANUAL-001 Title : Daralbeida Platform — Administrator User Manual Version : 1.0 Status : ACTIVE Style : BPGP Department : OPS Date Created : 2026-06-03 Date Revised : 2026-06-03 Last Modified : 2026-06-03 KB Category : WEB-FRONTEND Filename : DARX_OPS_ADMIN_MANUAL_20260603.txt Review Cycle : On change to admin UI or entity-creation procedure. Retention : Life of the platform plus two years. Owner : PYB / Daralbeida Distribution : Daralbeida web engineering and platform operators. COMPLIANCE : Operational tasks documented step by step for repeatability. Revision History: Ver Date Summary of Changes 1.0 2026-06-03 Initial issue. END OF DOCUMENT