The Config Item

Everything Configuard does starts from a list of config items. One item is one setting — a row in a tall key / value table, carrying its own metadata.

Why a Vertical Table

Configuration is a long, ever-growing list of individual settings that changes across environments and over the life of a product. A tall key/value table lets you add, edit, or remove one setting at a time — each row carrying its own type, access level, options, and flags — and administer it from a UI without schema migrations. That beats wide, one-column-per-setting tables or settings scattered across files.

The cost is that flat rows are good to store, not to consume: values are strings, related keys are scattered, and the same value is often duplicated. Configuard closes that gap.

IConfigItem

Each row implements IConfigItem:

Field	Type	Meaning
accessor	AccessorType	system / application / all. See Access Control.
appAccess	number | null	Bitwise flags for application clients (ABAC).
key	string	Dot/bracket notation; a leading @ marks an option list.
type	ValueType	How value is parsed. See Value Types.
listType	ListType	none / array / csl. See List Types.
value	string | null	The raw value to parse; may contain ${...} templates.
options	string | null	Allowed values, or a "${@name}" option-list reference.
defaultValue	string | null	Factory value, for reverting.
requiresReboot	boolean	Whether changing it requires a reboot.
editable	boolean	Whether the accessor may edit it.
encrypt	boolean	Whether the value is encrypted at rest.
description	string | null	Human-readable description.

Configuard.isConfigItem(o) is the matching type guard.

The Reference Table

The rows mirror a config table. A reference schema:

schema.sql

-- A vertical key → value `config` table. Each row is one setting, carrying its
-- own metadata (type, access level, options, requiresReboot, …) so settings can
-- be added, edited, or removed one at a time — no schema migrations.
CREATE TABLE `config` (
  `accessor`       enum('system','application','all') NOT NULL DEFAULT 'system',
  `appAccess`      int unsigned        DEFAULT NULL,  -- bitwise flags (ABAC)
  `key`            varchar(255)        NOT NULL DEFAULT '',   -- dot/bracket notation; leading `@` = option list
  `type`           enum('null','string','boolean','number','integer','float','hexadecimal','datetime','date','time','regexp','json','any') NOT NULL DEFAULT 'null',
  `listType`       enum('none','array','csl') NOT NULL DEFAULT 'none',
  `value`          varchar(5000)       DEFAULT NULL,  -- raw string; may hold `${...}` templates
  `options`        text                DEFAULT NULL,  -- allowed values, or a `${@name}` option-list ref
  `defaultValue`   varchar(5000)       DEFAULT NULL,  -- factory value, for reverting
  `requiresReboot` tinyint unsigned    NOT NULL DEFAULT '0',
  `editable`       tinyint unsigned    NOT NULL DEFAULT '1',
  `encrypt`        tinyint unsigned    NOT NULL DEFAULT '0',
  `description`    text                DEFAULT NULL,
  UNIQUE KEY `config_uniq_key` (`key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Configuration items table.';

The value column stays a string in storage — Configuard parses it on the way out and serializes it on the way back in.

Special Keys

Two key shapes are treated as metadata, not as plain config values:

• @-prefixed keys define a reusable option list (e.g. @UIColors). They are excluded from the built object.
• Section markers — a key whose last note starts with $ (e.g. cp.config.$title) is section metadata for an admin UI, and is skipped during the build.

Tip

Both are ignored by build(). Option-list keys come back when you call parseFlat(); section markers are always build-time noise and never appear in .data.