About:Pharmacopedia.ext: Difference between revisions

(25 intermediate revisions by the same user not shown)

Line 1:

~~{{TOC right}}~~

'''Version:''' 0.9.8.7 · '''Requires:''' MediaWiki >= 1.46.0 · PHP >= 8.5

~~= Pharmacopedia extension specification =~~

'''Version:''' 0.9.0 · '''Requires:''' MediaWiki >= 1.46.0 · PHP >= 8.5

'''Author:''' MDElliottMD · '''License:''' GPL-2.0-or-later

'''Source:''' <code>/var/www/mediawiki/extensions/Pharmacopedia/</code>

The Pharmacopedia extension turns a MediaWiki install into a structured, community-edited medicine reference with rich user-profile and ~~assessment~~ infrastructure. It adds parser tags, special pages, API modules, a chip-picker / autosave UI framework, and a database schema that together support:

The Pharmacopedia extension turns a MediaWiki install into a structured, community-edited medicine reference with rich user-profile, assessment, life-story, and visibility-sharing infrastructure. It adds parser tags, special pages, API modules, two dark skins, a chip-picker / autosave UI framework, a vis-timeline-based visual life timeline, a granular per-record sharing subsystem, an observer-perspective subsystem, a token-gated subsystem for administering assessments to people outside the wiki, a two-origin diptych front-of-house, and a database schema that together support:

* Structured medicine pages via the <code><nowiki>{{MedTemplate}}</nowiki></code> template

* Per-user rating on effects, problems, titration strategies, anecdotes, and drug-drug interactions (continuous 0–100 sliders, ±100 valence; no 0–5 likert anywhere)

* Per-user rating on effects, problems, titration strategies, anecdotes, and drug-drug interactions (continuous 0–100 sliders, ±100 valence; no 0–5 likert anywhere); ratings use a hold-to-expand star widget (300 ms press, spring animation, drag-commit with pixel-travel + value-delta guards); voters can remove their own committed rating

* Binary AND choice/multi voting on arbitrary content (<code>type="single"</code> / <code>type="multi"</code> with 2-5 options, results-visibility policy per element)

* Two-perspective data capture (personal vs. provider) wherever clinically meaningful

* User profile with dimensional personality / autism assessments (CATI, CAT-Q, MBTI, Enneagram, PID-5-BF, OCEAN/BFI-10) and rich auto-generated reports

* Diagnosis autocomplete backed by ~25,500 ICD-10-CM ~~and ~15~~,~~800~~ ICD-11 codes

* Further self-report instruments (BPNS, NFCS, OCI-PCP, WHOQOL-BREF) and the HYD-PCP wellbeing check-in, on the same auto-scored, report-bearing pattern

* ADHD screening (ASRS and AMAAS-SR) plus a Formal testing log of standardized-test scores, every score field carrying its own visibility

* Diagnosis autocomplete backed by ~41,500 ICD-10-CM, ICD-11, and DSM-5 codes

* '''Life-story timeline''': visual swimlanes (vis-timeline 7.7.3, vendored Apache-2.0) plus a synchronized trait-trajectory overlay (vis.Graph2d); card-list view alongside; quick-add free-text observation parser; range-date episode form with severity slider

* '''Per-record sharing subsystem''': rule types include public, private, users, cohort, link_token, reciprocal; time-bounded; audit log of who-viewed-what; bulk free-text → structured ref upgrader; privacy mode that disables legacy fallback

* '''Observer perspectives''': token-gated, no-account second-party input on something a user owns, under a two-gate consent model

* '''Administer to others''': send any registered assessment scale to people outside the wiki by one-time link, collect their results, and follow them over time, under per-owner public-key encryption with an optional zero-knowledge passphrase mode

* '''Two-origin diptych''': the Main Page and Category index render as chromeless full-viewport splashes giving the pharmaceutical and plant origins equal face

* Chip-picker / autosave / slider-precise-input UI framework shared across editor surfaces

* Date + time + range kit: PCPDatePicker (point/range/possibility), PCPTimePicker (fuzzy time-only: "4p", "noon", "quarter past 6")

* Verified-provider role with document-based verification

* Fail-closed ClamAV scan on every image / file upload (hard project rule)

* Per-user '''research_id''' (stable 10-char hex, opaque, never reassigned) for de-identified research participation

== Precision doctrine ==

Line 29:

Line 37:

== High-level architecture ==

* '''Backend (PHP):''' <code>includes/</code>, one class per parser tag, store, special page, or API module. Auto-loaded under <code>MediaWiki\Extension\Pharmacopedia\</code>. Assessment classes under <code>includes/Assessments/</code>.

* '''Backend (PHP):''' <code>includes/</code>, one class per parser tag, store, special page, or API module. Auto-loaded under <code>MediaWiki\Extension\Pharmacopedia\</code>. Assessment classes under <code>includes/Assessments/</code>. API modules under <code>includes/Api/</code>.

* '''Frontend (JS):''' <code>~~resources/~~ext.pharmacopedia~~.js~~</code>, ~~single IIFE binding click handlers~~, ~~modals~~, ~~chip~~-~~pickers~~, ~~autocomplete~~, autosave ~~debouncer~~, slider-~~precise click~~-to-~~type~~. <code>~~resources~~/ext.pharmacopedia.~~blocksave~~.js</code> is the ~~autosave infrastructure~~ (~~debounced AJAX per block~~, ~~race~~-~~safe~~).

* '''Frontend (JS / CSS):''' multiple ResourceModules per surface area:

* '''~~Styles~~ (CSS):''' <code>~~resources~~/~~ext~~.~~pharmacopedia~~.~~css~~</code>, ~~shared~~ row ~~layout~~, per-~~tag chrome~~, ~~dark~~-~~theme palette~~ (~~black~~ / ~~dark~~-~~grey~~ / ~~purple~~ / ~~white primary~~; ~~red~~ / ~~green~~ / ~~blue~~ / ~~teal sparingly for semantic distinction~~).

** <code>ext.pharmacopedia</code>: main IIFE (chip-picker, dx autocomplete, BFI-10 compute, vote logic for both binary and choice/multi, hold-to-expand star rating model with spring animation and drag-commit, vote removal)

* '''~~Datepicker~~:''' <code>~~resources~~/~~ext~~.pharmacopedia.~~datepicker~~.js</code> + <code>.~~css~~</code>, ~~supports~~ single ~~dates~~, ~~ranges~~, and ~~possibility~~-~~mixed dates~~ (e.g. "~~1995~~ or ~~1996"~~).

** <code>ext.pharmacopedia.styles</code>: base extension stylesheet (self-hosted Geist / Newsreader / Source Serif fonts, core component styling)

* '''~~Schema~~:''' <code>~~sql~~/</code>, ~~~20 core tables~~ plus ~~migration patches~~. ~~Picked~~ up ~~via~~ <code>~~LoadExtensionSchemaUpdates~~</code> ~~hook~~.

** <code>ext.pharmacopedia.blocksave</code>: debounced autosave per block (race-safe)

** <code>ext.pharmacopedia.bounceback</code>: preserves the reader's scroll position across POST-then-reload actions via sessionStorage

** <code>ext.pharmacopedia.confirmdelete</code>: styled red warning prompt replacing <code>window.confirm()</code> on destructive actions

** <code>ext.pharmacopedia.datepicker</code> + <code>.datepicker.styles</code>: range / possibility-mix date widget

** <code>ext.pharmacopedia.timepicker</code> + <code>.timepicker.styles</code>: time-only widget (fuzzy parsing, extracted from DatePicker)

** <code>ext.pharmacopedia.share</code>: per-record share dialog (People / Link / Cohorts tabs)

** <code>ext.pharmacopedia.perspective</code>: observer-perspective form enhancement (slider readout, progress, consent/delete confirm)

** <code>ext.pharmacopedia.administer</code>: the administer-to-others surfaces (take-flow slider readout + "Not sure" toggling, owner-hub styling)

** <code>ext.pharmacopedia.editor</code>: editor enhancements loaded on <code>action=edit/submit</code>; smart paste converts bare PMID or DOI from the clipboard into a formatted <code><ref></code> tag (PubMed eutils / CrossRef); house-rules linter flags banned terms and em-dashes on submit with a dismissable warning; quick-ref stub (Ctrl+Alt+R) inserts a journal-article <code><ref></code> skeleton

** <code>ext.pharmacopedia.observation</code>: quick-add observation textarea + live preview

** <code>ext.pharmacopedia.refupgrade</code>: bulk linker for free-text → structured refs

** <code>ext.pharmacopedia.vis-timeline-vendor</code>: vis-timeline 7.7.3 (vendored)

** <code>ext.pharmacopedia.lifetimeline</code>: visual life-story timeline + swimlanes + toolbar

** <code>ext.pharmacopedia.lifegraph</code>: trait-trajectory overlay (vis.Graph2d) synced to timeline

** <code>ext.pharmacopedia.kitsync</code>: glue that propagates kit-widget changes into legacy hidden inputs + drives privacy-mode toggle

** <code>ext.pharmacopedia.frontpage</code> / <code>ext.pharmacopedia.categoryindex</code>: the two diptych splash modules, each self-contained so it renders with no skin loaded

** <code>ext.pharmacopedia.appearance</code>: the collapsible Appearance rail (reader text-size control)

** <code>ext.pharmacopedia.skin.plants</code> / <code>ext.pharmacopedia.skin.fungi</code>: the earth-toned plants-skin overlay and the fungi sub-skin override layer

* '''Schema:''' <code>sql/</code>, roughly three dozen core tables plus migration patches. Picked up via the <code>LoadExtensionSchemaUpdates</code> hook.

== Security & encryption ==

Pharmacopedia stores deliberately personal data, including self-reports across mood, addiction, sexuality, and clinical history. The cryptographic + operational posture below is documented in detail so that a security researcher can read it in one pass and know exactly what is on the ground. Values are quoted verbatim where they are already observable from the public surface (HTTP headers, TLS handshake, public APIs); secrets and rotation policy are described without disclosing their values.

=== Transport ===

TLS terminates at Apache 2 (mod_ssl) on the same host as the application. No CDN, no reverse proxy, no load balancer is in front. Certificate is a Let's Encrypt ECDSA leaf, renewed by <code>certbot.timer</code> (fires twice daily, renews when within 30 days of expiry). Private key on disk is mode 600 root:root in <code>/etc/letsencrypt/archive/pharmacopedia.wiki/</code>.

Apache TLS config (live from <code>/etc/letsencrypt/options-ssl-apache.conf</code> + <code>/etc/apache2/mods-enabled/ssl.conf</code>):

SSLProtocol all -SSLv3

SSLCipherSuite HIGH:!aNULL

SSLSessionTickets off

Effective TLS range: TLS 1.0 through 1.3 (SSLv3 explicitly refused). The cipher suite shorthand <code>HIGH:!aNULL</code> covers all ECDHE + DHE forward-secrecy ciphers but does not exclude TLSv1.0 or TLSv1.1 at the protocol layer. Hardening to an explicit modern list and <code>SSLProtocol -TLSv1 -TLSv1.1</code> is queued; see ''Honest limitations'' below. <code>SSLSessionTickets off</code> preserves forward secrecy across server restarts.

HSTS:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Two years, subdomains included, preload-ready. The <code>preload</code> directive is present in the header; submission to the Chromium HSTS preload list is pending.

=== HTTP security headers ===

Set at the Apache layer (<code>/etc/apache2/conf-enabled/security-headers.conf</code>), not relying on PHP:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://challenges.cloudflare.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; media-src 'self' blob:; font-src 'self' data:; object-src 'none'; frame-src 'self' https://challenges.cloudflare.com; worker-src blob:; base-uri 'self'; form-action 'self';

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Referrer-Policy: strict-origin-when-cross-origin

X-Frame-Options: SAMEORIGIN

Permissions-Policy: geolocation=(), camera=(self), microphone=(), payment=()

X-Content-Type-Options: nosniff (set by MediaWiki)

<code>'unsafe-inline'</code> + <code>'unsafe-eval'</code> are required by MediaWiki's JS/CSS pipeline; <code>challenges.cloudflare.com</code> is whitelisted only for the Cloudflare Turnstile widget. <code>object-src 'none'</code> blocks Flash/applet vectors; <code>base-uri 'self'</code> blocks base-tag hijack; <code>form-action 'self'</code> blocks off-origin form POST. No COOP / COEP / CORP set: MW does not need cross-origin isolation.

=== Apache file filters + URL redaction ===

A backup-pattern denylist applies under the document root:

Require all denied

</FilesMatch>

This closes editor swap files, ad-hoc <code>.pre-<feature></code> snapshots, <code>.orig</code> merge debris, and emacs / vim trailing-tilde backups (a source-disclosure path closed 2026-05-20).

Skin asset directories run a positive allowlist (default-deny, only the whitelisted suffixes are served):

Require all denied

</FilesMatch>

The web installer at <code>/mw-config/</code> is 403'd at the vhost layer regardless of any <code>$wgUpgradeKey</code> value.

Token-bearing URLs are redacted from access logs by <code>/etc/apache2/conf-enabled/pcp-log-redaction.conf</code>. Pharmacopedia issues two URL families that carry per-request secrets in the path: <code>Special:RespondToAssessment/<token></code> (the invite token derives the AES key for the respondent-readable AdminCrypto copy) and <code>Special:Perspective/<token></code>. The redaction rule rewrites the request URI in the access log to a literal "[pcp: token-bearing URL redacted]" while preserving IP, time, method, status, byte count, and User-Agent. Three match-paths (request URL, Referer, query string) cover navigation, subresource, and <code>?title=</code> invocations.

=== PHP-FPM hardening ===

Production pool <code>/etc/php/8.5/fpm/pool.d/mediawiki-prod.conf</code> runs as <code>www-data</code> on an UDS socket (<code>0660 www-data:www-data</code>), <code>pm = ondemand</code>, <code>pm.max_children = 16</code>, <code>pm.max_requests = 500</code> (workers cycle every 500 requests to recover memory). Per-pool <code>open_basedir</code> restricts filesystem access to the small set of directories the wiki actually needs:

/var/www/mediawiki, /tmp, /var/log/mediawiki, /var/lib/php,

/var/cache/mediawiki, /var/lib/pharmacopedia-verification,

/var/lib/pharmacopedia-literature, /var/lib/pharmacopedia-life,

/usr/bin, /dev/null, /dev/urandom,

/var/lib/pharmacopedia-feature-requests,

/var/lib/pharmacopedia-adminkeys, /var/lib/mwoauth2

A workspace outside this list is unreadable from PHP regardless of file mode.

ini hardening: <code>expose_php = Off</code>, <code>display_errors = Off</code> (errors go to log only), <code>allow_url_include = Off</code> (remote-PHP include attack vector closed; <code>allow_url_fopen = On</code> stays because MW needs upload-from-URL). Session cookies: <code>secure = 1</code>, <code>httponly = 1</code>, <code>samesite = "Lax"</code>, <code>use_strict_mode = 1</code>, <code>use_only_cookies = 1</code>, session-end lifetime, 24-minute idle gc. opcache enabled with <code>validate_timestamps = 1</code> + 2-second revalidate (no stale-code-after-deploy risk).

=== Database ===

MariaDB 10.11.14, <code>bind-address = 127.0.0.1</code> only (the loopback). DB ports are not exposed to the network; UFW does not need a rule because the bind never reaches the wire. <code>sql_mode</code> includes <code>STRICT_TRANS_TABLES</code> + <code>ERROR_FOR_DIVISION_BY_ZERO</code> (strict type + math behavior). <code>have_ssl = DISABLED</code> is deliberate (loopback-only connections do not benefit from TLS overhead). The wiki's DB account is scoped to the two MW schemas (<code>mediawiki</code>, <code>mediawiki_staging</code>); no <code>FILE</code>, no <code>SUPER</code>, no <code>GRANT OPTION</code>. A DB compromise via injection is bounded to those two schemas.

=== SSH + host ===

<code>sshd</code> is key-only (<code>PasswordAuthentication no</code>, <code>KbdInteractiveAuthentication no</code>, <code>PermitEmptyPasswords no</code>), <code>PermitRootLogin prohibit-password</code> (root accessible only with an authorized key), <code>MaxAuthTries 6</code>, X11 forwarding off. Modern key exchange algorithms preferred (sntrup761x25519, curve25519); legacy SHA1 MACs left in the list for client compatibility.

UFW is deny-by-default for incoming traffic, allow-all outgoing. The only open ingress ports are 22/tcp, 80/tcp, and 443/tcp. The database, the SMTP relay, and the application cache are all loopback-only.

fail2ban runs five jails: <code>sshd</code>, <code>apache-auth</code>, <code>apache-badbots</code>, <code>mediawiki-auth</code> (matches failed wiki logins by spotting <code>200</code> responses on POSTs to <code>Special:UserLogin</code> / <code>Special:CreateAccount</code> — successful logins redirect <code>302</code>), and <code>web-scanners</code> (matches the usual probe patterns).

=== Secrets and keys on disk ===

The high-trust paths and their modes (no values published):

/var/www/mediawiki/LocalSettings.php 640 root:www-data

contains: $wgSecretKey, $wgUpgradeKey, $wgDBpassword,

$wgTurnstileSecretKey, $wgSMTP['password'],

$wgPharmacopediaVoteHashSecret,

$wgOAuth2{Private,Public}Key paths

/root/.backup-passphrase 600 root:root (64 bytes random)

/var/lib/mwoauth2/oauth-private.key 600 www-data:www-data (RSA-4096)

/var/lib/mwoauth2/oauth-public.key 644 www-data:www-data

/var/lib/pharmacopedia-adminkeys/ 700 www-data:www-data

master.key (lazy-provisioned on first Mode B owner) 600 www-data:www-data

/etc/exim4/passwd.client 640 root:Debian-exim

/etc/letsencrypt/archive/.../privkey1.pem 600 root:root

/root/.config/rclone/rclone.conf 600 root:root

Public values that are safe to read:

* Cloudflare Turnstile site key: <code>0x4AAAAAADMu_bvOguDp0U52</code>

* Backup target: <code>dropbox:pharmacopedia-backups</code> (Dropbox holds only AES-256-encrypted bundles; the passphrase never leaves the host)

Rotation policy:

* <code>$wgSecretKey</code> is NOT rotated (would invalidate every session and signed-state cookie).

* <code>$wgUpgradeKey</code> rotated 2026-05-22 to 256 bits.

* <code>$wgPharmacopediaVoteHashSecret</code> is intentionally never rotated (rotation invalidates every voter-state mapping, retroactively breaking voter anonymity for existing votes).

* TLS private key rotates on Let's Encrypt renewal (automatic, twice-daily check).

* AdminCrypto Mode B master key + OAuth2 RSA keypair are NOT rotated today; rotation would invalidate existing wrappings + outstanding tokens. Future rotation is overlap-aware (re-wrap under new key, accept either during the cutover window).

=== Application-layer cryptography ===

==== Passwords and second factor ====

MediaWiki passwords are stored as PBKDF2 hashes (MW core default). Verified across every <code>user_password</code> row: HMAC-SHA-512 inner hash, 30,000 iterations, 64-byte derived key, 16-byte random salt per user. The <code>$wgPasswordConfig</code> default is unmodified; bcrypt is available in MW core but not enabled.

Two-factor authentication via the OATHAuth extension. Default module is TOTP per RFC 6238: HMAC-SHA-1 inner, 6 digits, 30-second time-step, 80-bit shared secret. Five recovery codes per user, each a random string, hashed at rest, consumed on use. WebAuthn / FIDO2 (passkey) is available in the same extension and is the operator's first-choice path.

==== AdminCrypto ====

The "Administer to others" subsystem uses a per-owner asymmetric envelope so that respondents can submit results without an account and the owner can decrypt while absent. Implementation (<code>extensions/Pharmacopedia/includes/Assessments/AdminCrypto.php</code>):

Per-owner X25519 keypair generated via <code>sodium_crypto_box_keypair()</code> (libsodium, kernel CSPRNG). The public key is stored in the clear; the secret key is wrapped at rest in <code>pcp_administer_userkey.uk_wrapped_seckey</code> with AES-256-GCM (12-byte fresh IV per call, 16-byte authentication tag, empty AAD; wrapped layout: <code>IV || ciphertext || tag</code>).

Respondent submissions are sealed to the owner's public key via <code>crypto_box_seal</code> (libsodium, anonymous X25519 sender): anyone can encrypt with the public key; only the owner can decrypt with the secret key.

Two key-custody modes:

* '''Mode A (passphrase, zero-knowledge).''' The wrap key for the owner's X25519 secret key derives from a passphrase the server never stores, via Argon2id (libsodium <code>sodium_crypto_pwhash</code> with <code>ARGON2ID13</code>). Two version tracks: v1 uses INTERACTIVE limits (2 ops, 64 MiB memory); v2 uses MODERATE limits (3 ops, 256 MiB memory). The 16-byte salt is stored in <code>uk_kdf_salt</code>; the derivation produces a 32-byte wrap key and a 32-byte verifier (domain-separated SHA-256 of the wrap key). Older-version owners are transparently re-wrapped to the current KDF version on their next successful unlock. ''In Mode A, a database leak alone yields nothing the attacker can decrypt without the owner's passphrase, by design.''

* '''Mode B (managed key).''' The wrap key is a 32-byte random AES-256-GCM key in <code>/var/lib/pharmacopedia-adminkeys/master.key</code> (mode 600 <code>www-data:www-data</code>), lazy-provisioned on first Mode B owner setup. The directory is excluded from the backup tar by path; a database-plus-backup leak does not yield decryption power, because the master key never enters the backup pipeline.

A separate respondent-readable copy of each submission is encrypted with a key derived from the invite token: <code>respondentKey = SHA-256("pcp-administer-respondent-v1:" || rawToken)</code>. The server never stores this key; the rawToken lives only in the URL handed to the respondent. The token-bearing URL is redacted from access logs (see ''Apache file filters'' above).

==== OAuth 2.0 (iOS app) ====

The iOS app authenticates against the wiki via the MWOAuth extension. RSA-4096 signing keypair generated 2026-05-22 with <code>openssl genrsa</code>; JWT signing algorithm RS256. Access tokens live 1 hour; refresh tokens 1 month (MWOAuth defaults). PKCE with S256 challenge is REQUIRED for public clients (<code>$wgOAuth2RequireCodeChallengeForPublicClients = true</code>); the iOS bundle never holds a client secret. Tokens are stored at rest in the wiki's session cache keyed by hashed token (the tokens themselves are opaque to the cache row). The browser-to-app handoff goes via a small HTML+JS bridge at <code>https://pharmacopedia.wiki/app/oauth-callback</code> that forwards the authorization code + state to the <code>pharmacopedia://oauth</code> custom URL scheme. Special:UserLogin and Special:CreateAccount also carry <code>autocomplete</code> field attributes (<code>username</code>, <code>current-password</code> / <code>new-password</code>, <code>email</code>) injected by the <code>AuthChangeFormFields</code> hook so iOS Safari + system password managers offer the right credentials on the right field.

==== Voter anonymity ====

Every vote stores a HMAC-SHA-256 of the voter's user id, salted with <code>$wgPharmacopediaVoteHashSecret</code> (256 bits, never rotated by policy). The hash is a 64-character hex string in <code>pcp_votes</code> in place of the user id, so an administrator reading the votes table cannot map a vote back to an identity without the secret. The secret lives only in LocalSettings.

==== Perspective-invite tokens ====

The perspective subsystem's invite tokens are 24-byte URL-safe random strings handed to invitees in <code>Special:Perspective/<token></code> links. As of 0.9.8.7, every new invite stores BOTH the cleartext token in <code>pcp_perspective_invite.pvi_token</code> AND a SHA-256 hash of the same token in a new <code>pvi_token_hash</code> column (<code>BINARY(32)</code>, <code>UNIQUE</code>). Lookup at <code>PerspectiveStore::resolveToken</code> hashes the inbound URL token and searches by hash first; a cleartext-column fallback covers any row not yet backfilled at deploy edge. Hashing reuses the canonical <code>AdminCrypto::hashInviteToken</code> helper (raw 32-byte SHA-256), the same shape as the existing <code>pcp_administer_invites.inv_token_hash</code> pattern.

Honest current status: this is half-shipped on purpose. The cleartext <code>pvi_token</code> column is still present so the lookup-fallback works during the dual-write cycle; 0.9.8.8 drops the cleartext column and the fallback branch, at which point a database-read attacker can no longer extract usable perspective-invite tokens.

=== Backups ===

<code>/usr/local/bin/pharmacopedia-backup.sh</code> runs daily at 03:15 local. Every artifact is GPG-symmetric encrypted with AES-256 before it touches the off-host stage:

gpg --batch --yes --symmetric --cipher-algo AES256

--passphrase-file /root/.backup-passphrase

GPG packet inspection on a current bundle confirms cipher 9 (AES256), S2K mode 3 (iterated and salted), S2K count 65,011,712 iterations, MDC method 2 (modification-detection code present). Local retention is 7 days; off-host (Dropbox via rclone) is 14 days as of 2026-05-23 (was 60). The passphrase file is 64 bytes random, mode 600 root:root, never transmitted off-host.

The 14-day window describes ACTIVE off-host storage: after 14 days the encrypted bundle is removed from the active view of the off-host provider by the nightly rotation. The current off-host provider (Dropbox Pro) additionally retains deleted files in a deletion-recovery layer for up to 180 days, during which the encrypted bundle may remain recoverable by the account operator; after that window the bundle is permanently and irrecoverably deleted. The bundle is GPG-AES256 encrypted at all times; the off-host provider cannot read it under any circumstance. This active-vs-recovery distinction is queued for removal once a B-side backend migration (Hetzner Storage Box BX11, SFTP, POSIX unlink, no recovery layer) ships; tracked in ''Honest limitations'' below.

The backup tar covers <code>/var/www/mediawiki/images</code>, <code>LocalSettings.php</code>, the Pharmacopedia extension, and local skin assets. The full <code>mediawiki</code> schema is dumped separately to a sibling SQL file (also encrypted). Deliberately excluded by path: the AdminCrypto master key, the OAuth2 RSA private key, the backup passphrase itself, the Gmail SMTP credential, and the Let's Encrypt private key. ''A leak of any single backup bundle does not yield Mode B decryption power, JWT signing power, or further off-host backup decryption — those keys live elsewhere on the host and are not in the bundle.''

=== Logging + audit ===

Apache access/error logs and the MediaWiki exception / error / dberror / fatal logs all rotate daily and retain 14 days, then delete. Log files are <code>640 root:adm</code> (Apache) and <code>640 www-data:adm</code> (MW); the world-readable mode that existed prior to 2026-05-22 was tightened in the same audit pass that hardened the rest of the host.

MW exception logs live at <code>/var/log/mediawiki/{exception,error,dberror,fatal}.log</code>. The <code>pcp_visibility_view_log</code> table records every permitted view through a share rule (rule type, viewer, timestamp); the table stores raw IP for anonymous viewers (no /24 mask today — a feature gap, not a privacy claim).

=== Abuse protection ===

* Cloudflare Turnstile gates account creation, repeated failed logins, URL-bearing edits, and email-sending. Editors are not challenged on normal edits (a deliberate friction trade-off).

* The AbuseFilter extension is loaded with 2 rules, both enabled as of 0.9.8.7. Rule 1: spam-keyword block (block + disallow). Rule 2: new-account edit throttle (throttle). The active rule set is small; the lane will grow as live-fire patterns emerge.

* Every file or image upload is scanned by ClamAV before the file moves into the persistent store. The scanner is run via <code>clamdscan</code> (persistent daemon, fast) with a fallback to <code>clamscan</code>. The gate is fail-closed: exit 0 = clean (proceed), exit 1 = infected (reject + unlink), any other exit = error (reject + unlink). A scanner crash never becomes a pass.

* fail2ban (see ''SSH + host'' above) bans abusive IPs at the network layer.

* No CDN or DDoS mitigation layer sits in front; a determined volumetric attacker can degrade availability. We do not claim 24/7 uptime.

=== Honest limitations ===

The posture above is reasonable for a single-operator project that handles personal data; it is not pretending to be anything else.

* '''Single point of failure.''' Host-root compromise yields AdminCrypto Mode B decryption, OAuth2 JWT signing, backup decryption (via the passphrase file), and outbound email impersonation. Defense-in-depth lives in per-key file separation + filesystem perms + open_basedir, but a root-on-host attacker who clears each gate gets everything.

* '''Backup-lag on deletion.''' When a user requests deletion, the live row is purged immediately; the encrypted bundle is removed from active off-host storage after 14 days; the off-host provider's deletion-recovery layer may keep the (still-encrypted) bundle recoverable by the account operator for up to 180 days after that, until it is permanently deleted. Disclosed in About:Privacy on the wiki and (with identical wording) in Oyami's PRIVACY.md. Queued: a backend migration to Hetzner Storage Box (POSIX unlink, no recovery layer) collapses the window to a clean 14 days.

* '''No CDN, no DDoS layer.''' One VM, three open ports, UFW + fail2ban. Hostile traffic can take the site down; it cannot exfiltrate.

* '''Some application-layer key rotation is "never" by design.''' The voter-hash secret and the AdminCrypto Mode B master key cannot rotate without breaking either anonymity or existing wrappings respectively. Loss of either key has the obvious one-time consequence; trading that off against the alternative (re-encrypt every historical record) was the deliberate choice.

* '''TLS allows TLSv1.0 and TLSv1.1.''' The live Apache literal is <code>SSLProtocol all -SSLv3</code>, which does not exclude older TLS protocol versions at the protocol layer. Hardening to an explicit modern cipher list with <code>SSLProtocol -TLSv1 -TLSv1.1</code> is queued.

* '''Perspective-invite tokens are half-migrated to hashed storage.''' 0.9.8.7 added the <code>pvi_token_hash</code> column, backfilled it, and switched the lookup to hash-first; the cleartext <code>pvi_token</code> column is still present so the dual-write fallback works during the deploy edge. 0.9.8.8 drops the cleartext column and the fallback branch, at which point a database-read attacker can no longer extract usable invite tokens. Severity in the interim: an attacker with DB read can still submit a perspective under a planted invite identity; not access to medical data.

=== Security researchers welcome ===

I'm a long-term privacy hobbyist, but new at building real infrastructure. I'm trying my best and honestly it seems world-class good to me (and claude), but if it's not. I need to know ASAP.

If you find anything worth flagging — vulnerability, weakness, design concern, or just an observation — email [mailto:info@pharmacopedia.wiki me] directly. No bug-bounty program; just genuine appreciation for the time and the love of [https://markelliottmd.com/pubkey.asc pretty darn good privacy]. No NDA, no scope restriction, no preferred-disclosure-window. Reach out for any reason.

== Skins, layout, and the Appearance rail ==

'''Two skins.''' Every page renders in one of two dark skins. The default '''pharmaceutical skin''' is the violet-on-near-black clinical identity. The '''plants skin''' is an earth-toned treatment (<code>ext.pharmacopedia.skin.plants</code>) applied to plant-origin medicine pages. Both skins are dark; there is no light mode. The '''fungi sub-skin''' (<code>ext.pharmacopedia.skin.fungi</code>) is a specialization of the plants skin for fungal medicine pages: a fungus page carries both the <code>pcp-skin-plants</code> and <code>pcp-skin-fungi</code> body classes, loading the plants base plus a fungi override layer (a damp cool-dark palette, a spore-dust grain, the mushroom mark, fungi section-marker hues); everything else inherits from the plants skin.

<code>Hooks::resolvePcpSkin</code> picks the skin. A content (medicine) page is read by its OWN DIRECT origin category: a direct <code>Category:Fungi</code> tag gives the fungi sub-skin (checked first), a direct <code>Category:Plants</code> tag gives the plants skin, anything else pharma. There is no recursive category walk, so a page sitting inside a dual-parented class category (Category:Psychedelics parents under both origins) is skinned by its own origin tag, not by its class. A category page has no single direct origin, so it is resolved by walking its category chain (plants only when the chain is purely plant).

'''Full-width layout.''' The content frame runs edge to edge rather than in a fixed-width column; prose is held to a readable measure by its own constraint, and the layout gutters are set by layout tokens.

'''The Appearance rail.''' A collapsible rail (<code>ext.pharmacopedia.appearance</code>) gives the reader appearance controls, currently a text-size control. The chromeless diptych splashes suppress the rail.

== Front-of-house: the diptych ==

The Main Page and the Category index are built as a '''two-origin diptych''': a pharmaceutical column and a plant column side by side, the two origins of the materia medica given equal face. Both render as '''chromeless full-viewport splashes'''. A <code>body.pcp-diptych-page</code> class, added by the <code>BeforePageDisplay</code> hook on those two pages, hides all Vector chrome, and the module supplies its own topbar and footer. A full-height two-origin split gradient runs the page edge to edge, the pharma dark on the left half and the plant dark on the right, a 1px seam down the middle, so the diptych reads top to bottom with no separate bands.

Two parser tags generate the diptych from live wiki data:

* <code><frontpage></code> (<code>FrontPageTag</code>), the Main Page: a featured medicine and featured plant medicine, class / Pharmako-volume browse lists, recently-updated lists, portal links, a status strip.

* <code><categoryindex></code> (<code>CategoryIndexTag</code>), the Category index: the pharmacological classes and the plant lineages as two side-by-side trees.

<code>DiptychChrome</code> supplies the shared topbar and footer for both. The modules are <code>ext.pharmacopedia.frontpage</code> and <code>ext.pharmacopedia.categoryindex</code>; each carries its own palette tokens so the splash renders correctly with no skin stylesheet loaded.

The topbar carries a '''live typeahead search''' as the leftmost item of the right-side topnav cluster. It debounces 180 ms, fetches up to 8 results per keystroke (min 2 chars), and renders an ARIA-combobox dropdown with arrow / Enter / Escape keyboard navigation. The fetch path is hybrid: <code>action=opensearch</code> first (fast prefix index across the eight content namespaces: main, Category, Enzyme, Receptor, Phenotype, USLegal, Problem, Effect), with a <code>action=query&list=search</code> fallback fired on zero hits so all-caps titles like LSD (which opensearch cannot case-insensitively prefix-match against a lowercase query) still resolve.

== Parser tags ==

Line 42:

Line 282:

! Tag !! Purpose !! Class

|-

| <code><vote></code> || ~~Generic~~ up/down ~~binary~~ vote ~~on an arbitrary slug~~ || <code>VoteTag</code>

| <code><vote></code> || Binary up/down (default) OR choice/multi when <code>type="single"</code> or <code>type="multi"</code> + <code>options="A; B; C"</code> (2-5 options, semicolon-separated). Optional <code>results="live\|after-vote\|hidden"</code> for tally-visibility policy. || <code>VoteTag</code>

|-

| <code><effect></code> || Therapeutic or adverse effect; patient + provider perspectives; provider freq slider 0–100; shared valence slider ±100 || <code>EffectTag</code>

Line 54:

Line 294:

| <code><anecdote></code> || Personal or provider story with up/down vote || <code>AnecdoteTag</code>

|-

| <code><problem></code> || A problem ~~(formerly "indication")~~ the medicine addresses; 0–100 efficacy likert slider + "don't know" toggle || <code>ProblemTag</code>

| <code><problem></code> || A problem the medicine addresses; 0–100 efficacy likert slider + "don't know" toggle || <code>ProblemTag</code>

|-

| <code><pharmaInteractions/></code> || Self-closing; renders the Interactions section for the current page || <code>InteractionTag</code>

|-

| <code><pharmaExperience/></code> || Self-closing; renders the Experience report form (efficacy, burden, dose, route, schedule, stop-reasons) || <code>ExperienceTag</code>

|-

| <code><pharmaLiterature/></code> || Self-closing; per-medicine "Relevant literature" section: approved <code>pcp_literature</code> entries plus a collapsed submission form || <code>LiteratureTag</code>

|-

| <code><classGrid/></code> || A grid of medicine-class categories (those tagged Category:MedCategory); <code>count</code> + <code>exclude</code> attributes; 5-minute cache || <code>ClassGridTag</code>

|-

| <code><classTree/></code> || The MedCategory classes as a hierarchy with member counts; <code>exclude</code> attribute; 5-minute cache || <code>ClassTreeTag</code>

|-

| <code><frontpage/></code> || The two-origin diptych Main Page (see [[#Front-of-house: the diptych|Front-of-house]]) || <code>FrontPageTag</code>

|-

| <code><categoryindex/></code> || The two-origin diptych Category index || <code>CategoryIndexTag</code>

|-

| <code><pharmaCommonUses>...</pharmaCommonUses></code> || Medicine-page sidebar "Common uses": top-5 problems by rater count, ranked desc; falls back to the legacy hand-entered <code>uses</code> wikitext when zero problems are linked || <code>CommonUsesTag</code>

|-

| <code><problemMedicines slug="X"/></code> || Auto-generated list of medicines that carry a <code><problem ref="X"></code>. Used on every Problem:<Name> namespace page so the canonical "Medicines used for X" section maintains itself || <code>ProblemMedicinesTag</code>

|-

| <code><effectMedicines slug="X"/></code> || Auto-generated list of medicines that carry an <code><effect ref="X"></code>. Used on every Effect:<Name> namespace page so the canonical "Medicines that may cause X" section maintains itself || <code>EffectMedicinesTag</code>

|}

All non-self-closing tags take a <code>slug</code> argument and (where relevant) a <code>title</code>, <code>label</code>, <code>author</code>, <code>ref</code>, or <code>perspective</code>.

All non-self-closing rating tags take a <code>slug</code> argument and (where relevant) a <code>title</code>, <code>label</code>, <code>author</code>, <code>ref</code>, or <code>perspective</code>.

=== Tag wikitext examples ===

Line 81:

Line 337:

What's your favorite color?</vote>

<vote slug="side-effects" type="multi" results="after-vote"

options="Dry mouth; Insomnia; Anxiety; Headache; None">

Which side effects did you experience?</vote>

</pre>

Line 88:

Line 351:

! Element !! Scale !! Perspectives !! Storage

|-

| Vote tag || +1 / −1 binary || single || <code>pcp_votes</code>

| Vote tag (binary) || +1 / −1 binary || single || <code>pcp_votes.v_value</code>

|-

| Vote tag (single-choice) || one of 2-5 options || single || <code>pcp_votes.v_choices</code> (CSV index)

|-

| Vote tag (multi-choice) || any subset of 2-5 options || single || <code>pcp_votes.v_choices</code> (CSV indices)

|-

| Titration || +1 / −1 binary || single || <code>pcp_votes</code>

Line 103:

Line 370:

|}

Server-side aggregates: <code>n</code>, mean of the rating field, and (for interactions) <code>severe = (vmean ≤ −83.0)</code> (rescaled from the original ±3-scale −2.5).

Choice / multi vote elements expose per-option tallies via <code>tallyChoices()</code> on demand. Per-option bars render inline in the picker. The <code>results</code> attribute gates tally visibility:

* <code>live</code> (default), tally always visible

* <code>after-vote</code>, tally hidden until viewer has voted

* <code>hidden</code>, tally never shown (only options + "thanks" on submit)

Server-side options-hash (<code>ve_options_h</code>) detects post-vote option-list edits; the API rejects new votes whose submitted hash doesn't match the live one. Voter identities are stored as HMAC-SHA256 (<code>v_voter_hash</code>) so admins reading the DB cannot map votes to user accounts without the HMAC secret.

Server-side aggregates: <code>n</code>, mean of the rating field, and (for interactions) <code>severe = (vmean ≤ −83.0)</code> (rescaled from the original ±3-scale −2.5). Aggregates are recomputed and returned by every report-submit API call so the row re-renders in place without a page reload.

=== Hold-to-expand rating interaction ===

All <code>.pcp-rate</code> widgets (Common Uses stars, problem-tag stars, any future star widget) use a hold-to-expand pattern for precise rating. A 300ms press scales the widget toward a 483px target with a spring curve (<code>cubic-bezier(0.34, 1.56, 0.64, 1)</code>); drag while expanded commits on release when BOTH gates pass: pixel-travel >= 16px AND value-delta >= 0.2 on the 0-5 scale. A miss commits nothing; the widget springs back. Keyboard while expanded: arrow keys step +/- 0.2, Enter/Space commits, Escape cancels.

~~Aggregates are recomputed~~ and ~~returned by every report~~-~~submit API call so~~ the row re-~~renders~~ in ~~place without~~ a ~~page reload~~.

Reduced-motion (<code>prefers-reduced-motion</code>) drops the spring scale; the hold-and-drag gesture is preserved.

Vote-position marker: a third Unicode-star row clipped via <code>clip-path</code> inset, rendered in hot-pink (#ff2d78) stroke, shows the user's own committed vote distinct from the aggregate mean. Updates inline when the user re-rates.

Drag-path performance: <code>requestAnimationFrame</code> throttle plus cached widget bounds eliminate per-pointermove layout reads. Mobile parity: touch events (<code>touchstart</code>/<code>touchmove</code>/<code>touchend</code>) wired alongside pointer events. Companion CSS in <code>resources/ext.pharmacopedia.css</code> (~159 lines).

=== Vote removal ===

Voted state exposes a two-row layout via <code>.pcp-rate-row-top</code> (mean + n) and <code>.pcp-rate-row-bot</code> (voter's own value in hot-pink + 28px remove button). Row-bot hides cleanly when <code>data-voted</code> is absent so unvoted widgets render as a single line.

Clicking remove fires <code>POST action=pharmacopedialikert</code> with <code>vote=remove</code>. On 200: <code>data-voted</code> clears, the clip-path vote-position marker resets, <code>data-agg-n</code> decrements, the <code>localStorage</code> cache key is removed, and an <code>aria-live</code> region announces Your rating has been removed.

Two-row layout mirrors the PCPapp treatment for visual parity across web and mobile.

== Effect bucketing ==

Line 130:

Line 420:

<code>Special:MyProfile</code> is the user-facing editor for everything personal. Every block on it autosaves on a 800 ms debounce (see [[#Autosave infrastructure|Autosave infrastructure]]).

Visible at top: a Privacy-mode panel toggling whether legacy public fallback applies (privacy-mode ON = only explicit share rules grant access; OFF = the field-level <code>pf_visibility</code> enum applies).

🔗 Share chips appear in each fieldset legend (Demographics, Diagnoses, Medicines) so the owner can scope a share-rule to that namespace via the modal Share dialog.

=== Block list ===

* '''Identity''' (display alias, default attribution, experience-report visibility)

* '''Identity''' (display alias, default attribution, experience-report visibility, read-only Research ID badge)

* '''Demographics''' (full chip-picker rebuild, see below)

* '''Personality''' (Big Five OCEAN sliders + collapsible assessments)

* '''Enneagram''' (9 type sliders + 45-item screening test)

* '''MBTI''' (4 dichotomy sliders + 32-item OEJTS test)

* '''~~Personality / autism~~ assessments''' (PID-5-BF, CATI, CAT-Q, each as a collapsible inline test)

* '''Self-report assessments''' (PID-5-BF, CATI, CAT-Q, BPNS, NFCS, OCI-PCP, WHOQOL-BREF, HYD-PCP, each a collapsible inline test)

* '''ADHD screening''' (ASRS adult-ADHD screener and AMAAS-SR attention self-report, each a collapsible inline test)

* '''Formal testing''' (a log of standardized-test scores; raw score, percentile and pass/fail each carry their own privacy setting)

* '''Diagnoses''' (multi-row with ICD-10-CM + ICD-11 autocomplete, severity slider 0–100, disability slider 0–100, status, origin, dates, notes)

* '''Medicines I have tried''' (multi-row with med-name autocomplete, dose, route 16-option dropdown, schedule with datalist suggestions, efficacy + burden sliders 0–100, periods via date-picker)

Line 146:

Line 442:

All categorical demographics use the chip-picker widget (single or multi, with optional primary marker, optional custom free-text). All quantitative demographics use numeric inputs or structured composite widgets.

* '''Birthday''' DatePicker (single / range / possibility-mix)

* '''Birthday''' DatePicker (single / range / possibility-mix). Setting (or changing) the birthday auto-syncs a TYPE_STORY life event tagged <code>auto-birth</code> titled 'Born!' on the life-story timeline. Subsequent birthday edits move ONLY the event's date; user edits to title, body, tags, images are preserved.

* '''Sex assigned at birth''' single-select (clinical category)

* '''Gender identity''' multi-select chip-picker, 27 common terms + custom

Line 155:

Line 451:

* '''Height / weight''' unit toggle (Metric cm/kg or US ft+in/lb); stored canonically as cm/kg regardless

* '''Handedness''' single-select (3 options)

* '''Smoking''' structured widget: status + cigs/day + years smoked + quit date; auto-computes pack-years

* '''Smoking''' structured widget: status + cigs/day + years smoked + quit date (PCPDatePicker); auto-computes pack-years

* '''Alcohol''' structured widget: drinks/week + typical drink type + max one occasion

* '''Education''' bucketed highest-level + numeric years + free-text field of study

Line 165:

Line 461:

* '''Number of children''' numeric

* '''Time zone''' free text, auto-detects IANA TZ on first load if empty

* '''Chronotype / sleep schedule''' two ~~time inputs~~ (typical bedtime, typical wake)

* '''Chronotype / sleep schedule''' two PCPTimePicker widgets (typical bedtime, typical wake; fuzzy parsing accepts "10p", "bedtime", "quarter past 6")

* '''Political orientation''' two-axis compass sliders (economic ±100, social ±100)

Line 188:

Line 484:

Autocomplete via <code>action=pharmacopediadxsearch</code>, multi-token AND search (e.g. "ADHD inattentive" matches the F90.0 row that contains both substrings); ORDER BY <code>FIELD(da_system, 'ICD-10-CM', 'ICD-11', 'DSM-5', ...)</code> so ICD-10-CM leads, then ICD-11, then everything else.

=== ~~Personality / autism~~ assessments ===

=== Self-report assessments ===

~~Six~~ assessments, all ~~with~~ continuous-slider items, "Not sure" toggle per item, auto-computed subscale + total scores, and a rich auto-generated report at <code>Special:MyAssessment/{key}</code>:

The six dimensional assessments all have continuous-slider items, a "Not sure" toggle per item, auto-computed subscale + total scores, and a rich auto-generated report at <code>Special:MyAssessment/{key}</code>:

{| class="wikitable"

Line 208:

Line 504:

|}

All assessment items submit raw responses to <code>~~pcp_user_profile_fields~~</code> under namespace <code>{key}_raw</code> (e.g. <code>cati_raw</code>); the computed scores live under namespace <code>{key}</code> with keys like <code>subscale_SOC</code>, <code>total</code>, plus a <code>taken_at</code> timestamp. Re-scoring happens automatically on every save (autosave fires `scoreResponses()` on the full raw set, skipping "unsure" rows).

Five further self-report instruments are available on the same collapsible-inline-test, auto-scored, report-bearing pattern:

{| class="wikitable"

! Instrument !! Items !! Structure !! Measures

|-

| '''BPNS-PCP''' || 21 || 3 subscales (Autonomy, Competence, Relatedness), 7-point Likert || basic psychological need satisfaction, per Self-Determination Theory

|-

| '''NFCS-PCP''' || 15 || 5 facets (Order, Predictability, Decisiveness, Ambiguity intolerance, Closed-mindedness), 6-point Likert || need for cognitive closure (brief 15-item Roets & Van Hiel form)

|-

| '''OCI-PCP''' || 18 || 6 subscales (Washing, Obsessing, Hoarding, Ordering, Checking, Neutralizing), 0–4 per item; screening cutoff total ≥ 21 || obsessive-compulsive symptoms, adapted from the OCI-R

|-

| '''WHOQOL-BREF-PCP''' || 26 || 4 domains (Physical, Psychological, Social, Environment) + 2 overall items, 5-point Likert || quality of life

|-

| '''HYD-PCP''' || 8 || 8 single-item domains, each one bipolar slider (−100 really poorly to +100 really well); no subscales, no cutoffs || everyday wellbeing, re-taken and watched over time; a locally authored check-in, not validated

|}

All assessment items submit raw responses to <code>pcp_profile_fields</code> under namespace <code>{key}_raw</code> (e.g. <code>cati_raw</code>); the computed scores live under namespace <code>{key}</code> with keys like <code>subscale_SOC</code>, <code>total</code>, plus a <code>taken_at</code> timestamp. Re-scoring happens automatically on every save (autosave fires <code>scoreResponses()</code> on the full raw set, skipping "unsure" rows). Each completed assessment also auto-upserts a Life-story keyframe row (see [[#Life-story timeline|Life-story timeline]]) so trajectories plot over time.

All thirteen assessments (the six dimensional, these five, and the two ADHD screeners below) are registered in <code>AssessmentRegistry</code> and so can also be administered to outside respondents (see [[#Administer assessments to others|Administer assessments to others]]).

=== ADHD screening ===

Two attention / ADHD instruments sit alongside the dimensional assessments, each a collapsible inline test on <code>Special:MyProfile</code> and a card render on the public profile:

* '''ASRS''' (Adult ADHD Self-Report Scale, Part A): a 6-item binary screener. The card counts how many of the 6 cardinal items fall in the screening range; 4 or more is a positive screen. The public profile renders it as a '''verdict card''', a screen-positive or screen-negative result word with a 6-cell cardinal-item strip and a screening-result detail line.

* '''AMAAS-SR''' (a 30-item experimental attention self-report): three symptom subscales, inattention, hyperactivity and impulsivity, each scored as a percentage of the subscale maximum. The public profile renders it as a '''featured radar card''', a 3-axis radar carrying a deliberately arbitrary 66.66% threshold triangle that is labelled experimental and not a validated cutoff. AMAAS has no validated norms; the card discloses this in plain sight rather than presenting a clinical cutoff.

Both instruments store responses in <code>pcp_profile_fields</code> under the <code>asrs</code> and <code>amaas</code> namespaces, the same pattern as the dimensional assessments.

=== Formal testing ===

The '''Formal testing''' block on <code>Special:MyProfile</code> is a log of standardized tests the user has taken (entrance exams, AP exams, IQ tests, and the like; retakes are welcome, and the year disambiguates them). Each entry resolves against a catalog (<code>pcp_formal_tests</code>) or is a custom free-text test, and records up to three score fields, raw score, percentile and pass/fail, each with an optional estimate flag.

Every score field has its own '''per-field visibility'''. Raw score, percentile and pass/fail each carry a separate privacy setting (<code>uts_vis_raw</code>, <code>uts_vis_pct</code>, <code>uts_vis_passfail</code>), so a user can publish a percentile while keeping the raw score private. The <code>Special:MyProfile</code> editor shows three privacy toggles per entry; the public <code>Special:UserProfile</code> gates each score line independently by its own field visibility. Scores are stored in <code>pcp_user_test_scores</code>, managed through the <code>pharmacopediaformaltest</code> API.

== Life-story timeline ==

<code>Special:MyLifeStory</code> is the owner-facing editor + viewer for everything time-anchored about the user. Backed by <code>pcp_life_events</code> with extension columns for episode / observation / keyframe metadata.

=== Event types ===

{| class="wikitable"

! le_type !! Meaning !! Notes

|-

| 0 (TYPE_STORY) || Plain timeline entry || title, body, optional image

|-

| 1 (TYPE_IMAGE) || Image-primary entry || same shape, image is the main payload

|-

| 2 (TYPE_KEYFRAME) || Auto-created assessment snapshot || populated by <code>upsertAssessmentKeyframe</code> on every assessment save

|-

| 3 (TYPE_OBSERVATION) || Plain-text observation || created via the quick-add textarea; parser extracts date, polarity, refs

|-

| 4 (TYPE_EPISODE) || Time-bounded period || start + end (PCPDatePicker range mode); type / subtype / severity 0-100

|}

=== Quick-add observation ===

A textarea at the top of <code>Special:MyLifeStory</code> (and a 📝 modal trigger on <code>Special:MyProfile</code>) accepts plain text like:

<pre>

anxiety from bupropion in jan 2020

did not experience anxiety from bupropion in feb 2018

panic attack 2 months ago

depressed as a freshman

i had a manic episode sep 1 2020 till nov 15 2020

no insomnia while on melatonin in summer 2023

felt great on christmas 2020

happiest on my 30th birthday

</pre>

<code>ObservationParser::parse()</code> extracts:

* '''Date''' (point or range): ISO, MM/DD/YYYY, "Month D YYYY", "Month YYYY", "Season YYYY", "early/mid/late YYYY", bare year, decades ("2010s"); date RANGES via "X to Y", "X till Y", "from X to Y", "X - Y"; relative-to-now ("yesterday", "last week/month/year", "N months ago", "a few weeks ago"); holidays (christmas, halloween, new year's, valentine's, july 4th, thanksgiving with computed 4th-Thursday-of-Nov, MLK / Memorial / Labor day); age-relative ("7y8mo", "51.2yo", "at age 14", "ages 2-10"); life stages ("in childhood", "as a teen", "as a freshman", "junior year"); Nth birthday ("my 30th birthday")

* '''Polarity''' (negation detection): "not", "didn't", "did not experience", "never", "without", "denied" → polarity=0 (negative); else 1 (positive)

* '''Leading verbs stripped''': "I was diagnosed with", "I took", "started taking", "tried", "was on", "experienced", "felt", so the subject is the noun, not the verb

* '''Adverbs stripped''': "briefly", "occasionally", "frequently", "sometimes", "always", so the subject is the noun, not the modifier

* '''Role splitting''': "from / caused by / due to / while on" → role='cause'; "with / during / while" → role='context'

* '''Ref resolution''', in priority order:

*# User's meds (<code>pcp_user_meds</code>)

*# Wiki pages in Category:Medicines

*# Effects catalog (<code>pcp_effects</code>)

*# Problems catalog (<code>pcp_problem</code> + <code>pcp_problem_alias</code>)

*# User's diagnoses (<code>pcp_profile_diagnoses</code>)

*# Global ICD diagnosis abbreviations (<code>pcp_diagnosis_abbreviations</code>)

*# Free-text fallback (stored as type='free' for later upgrade)

* '''Auto-promote unrecognized subjects to custom-trait keyframes''': when the subject doesn't match an existing entity but the input has BOTH a numeric value AND a date (e.g. <code>my neuroticism was 5 at 10yo</code>), the subject is treated as a NEW custom trait (<code>namespace='custom'</code>, key derived from subject text). Creates a TYPE_KEYFRAME event with the value + a trajectory point. Future inputs with the same subject auto-append to that series.

* '''Flexible range separators''': <code>X to Y</code>, <code>X through Y</code>, <code>X thru Y</code>, <code>X until Y</code>, <code>X till Y</code>, em-dash, en-dash, flexible-whitespace hyphens (digit-aware so <code>2026-05-31</code> ISO dates aren't split), <code>..</code> / <code>...</code> ellipsis.

* '''Age-range phrases without literal "ages"''': <code>when I was 11-13</code>, <code>from 11 to 13</code>, <code>between ages 5 and 12</code>, <code>aged 10 to 14</code>. Negative lookahead prevents false matches on dosages (<code>10-20 mg</code>), durations (<code>5-10 years ago</code>), measurements (<code>cm/mm/ft/lb/etc</code>).

* '''Episode-shape detection''': "manic episode" → type=mood, subtype=manic; "psychotic break", "panic attack", "anxiety attack", "trauma response" all route to <code>addEpisode</code> instead of <code>addObservation</code>. A date RANGE alone is enough to force <code>is_episode=true</code>.

Live preview chips appear under the textarea as you type. Submit routes to <code>pharmacopediaobservation</code> API which writes the row + refs via <code>setEventRefs()</code>.

=== Episode form ===

Click the "🌀 Episode" button (or the quick-add detects an episode shape) for the structured form:

* Type selector: mood / psychotic / anxiety / panic / trauma response / dissociative / substance use / eating / sleep disturbance / pain flare / migraine / medication adjustment / hospitalization / creative surge / spiritual / transcendent / relationship crisis / grief / somatic / other

* Subtype (text + datalist), for mood: depressive / manic / hypomanic / mixed / dysphoric / euthymic

* Severity slider 0-100 (per precision doctrine)

* Date range via PCPDatePicker locked to range mode

* Title, body, single virus-scanned image, visibility (4-state)

=== Visual timeline ===

Top of <code>Special:MyLifeStory</code> has a tabbed view: '''Visual timeline''' (default) / '''Card list'''.

The visual timeline uses '''vis-timeline 7.7.3''' (vendored Apache-2.0 at <code>resources/vendor/vis-timeline/</code>) with these features:

* Swimlanes (toggleable chips): Episodes (range bars), Events, Observations, Keyframes (off by default), Derived

* '''Trait-trajectory overlay''': a synchronized <code>vis.Graph2d</code> draws smooth (centripetal Catmull-Rom interpolated) lines for every keyframe trait series (CATI subscales, PID-5-BF domains, CAT-Q, custom traits like "shyness") DIRECTLY on top of the timeline plot area. Same X-axis; the graph's data + time axes are CSS-hidden so only the lines + points show. Values are normalized to 0-100% within each series so different scales coexist.

* Toolbar: Visual/Card tabs, group toggle chips, magnifier + zoom +/- buttons, Fit visible / Fit everything

* Plain wheel = vertical scroll inside the timeline (520px fixed height); Ctrl+wheel = zoom; Shift+wheel = horizontal pan

* Click empty timeline area: prefills the quick-add textarea with "on YYYY-MM-DD" at that date + scrolls + triggers live preview

* Click an item: routes to its edit form (event / episode / observation, each has its own route)

* Collapsible "Trait series (N)" legend with chip toggles to show/hide individual series

=== Edit / delete / duplicate flows ===

Each event type has its own edit route under <code>Special:MyLifeStory</code>:

* <code>Special:MyLifeStory/edit-observation/<id></code>, re-parses raw text on save; supports polarity override + date override

* <code>Special:MyLifeStory/edit-episode/<id></code>, full episode form

* <code>Special:MyLifeStory?edit_event=<id></code>, existing event / image / keyframe form

All three forms have side-by-side "Delete X" + "Duplicate X" buttons. Duplicate copies fields + refs + keyframe traits (NOT images) and redirects to the new row's edit form.

=== Upgrade-link UI ===

When the parser stored a free-text ref (because the entity wasn't in the user's data at the time), <code>Special:MyRefLinks</code> finds all such refs and offers one-click "link to {match}" buttons. Matches come from the same catalogs the parser checks at write time. A banner on <code>Special:MyLifeStory</code> ("📎 N free-text references could be linked → Review & link") appears when unmatched refs exist.

== Per-record sharing subsystem ==

A granular per-record sharing system layered on top of the legacy <code>pf_visibility</code> enum without removing it. Resolved by <code>VisibilityResolver</code>; the new model is additive (legacy fallback preserved unless Privacy mode is on).

=== Rule types (vr_rule_type) ===

* '''<code>private</code>''', explicit deny (only owner)

* '''<code>public</code>''', explicit allow (anyone)

* '''<code>users</code>''', payload <code>{user_ids: [...]}</code>; allow if viewer in list

* '''<code>cohort</code>''', payload <code>{cohort_id: N}</code>; allow if viewer in <code>pcp_cohort_members</code> for that cohort

* '''<code>link_token</code>''', payload <code>{token: '...', uses_remaining: null|N}</code>; allow if URL <code>?pcpshare=TOKEN</code> matches

* '''<code>reciprocal</code>''', allow if viewer has a matching <code>users</code> rule sharing the same shape back to owner

Rules scope at three levels: <code>(profile, namespace, key)</code>, <code>(profile, namespace, NULL)</code>, or <code>(profile, '*', NULL)</code>. Most-specific-first matching. Rules can have <code>vr_expires</code> (time-bounded) and <code>vr_revoked</code> (preserves audit trail).

=== Privacy mode ===

When Privacy mode is ON for a profile, a *-wide <code>private</code> rule is created. <code>VisibilityResolver::canView()</code> short-circuits to false instead of falling through to the legacy <code>pf_visibility</code> check, so only explicit share rules grant access. Default: OFF (back-compat).

=== Share dialog ===

Triggered by 🔗 chips on assessment reports, profile sections, life-story timeline. Modal with three tabs:

* '''People''': username autocomplete (↓/↑/Enter/Esc keyboard nav), per-shared-user pill with × to remove just that user, optional expires DatePicker, "Auto-share back" reciprocal toggle

* '''Link''': "Generate link" creates a <code>link_token</code> rule; copies the URL to clipboard with toast; optional max-uses + expires

* '''Cohorts''': dropdown of the owner's cohorts (managed at <code>Special:MyCohorts</code>); optional expires

=== Audit log ===

Every permitted view through a rule (not legacy) writes a row to <code>pcp_visibility_view_log</code>. <code>Special:MyShareLog</code> shows the last 200 views with timestamp, viewer (or anonymous IP masked to /24), namespace, key, rule id.

== Observer perspectives ==

A structured way to collect second-party (observer) input on something a user owns, without the observer needing an account. The v1 use case is an observer-rated attention report: a registered user invites someone who knows them well to rate them. A two-gate consent model governs the whole flow.

* '''Gate 1, contribution.''' An owner-issued, token-bearing invite link is the only way to submit a perspective. The invitee URL carries only an opaque random token (<code>VisibilityResolver::generateLinkToken()</code>); the owner's identity is never in the URL. The invitee sees only the owner's chosen display name.

* '''Gate 2, publication.''' Every submission is born <code>psp_consent = 0</code>, private to the owner. Only the owner, re-checked for ownership, can flip it to published. A perspective is never publicly visible while unconsented.

Flow: the owner opens <code>Special:MyPerspectives</code>, picks a display name, mints an invite link, and sends it. The invitee opens <code>Special:Perspective/<token></code>, reads a generic intro and a non-anonymity notice, optionally states their relationship to the owner, fills the type-specific slider form (with per-item "not sure" markers), clears a Turnstile challenge, and submits. The perspective lands in the owner's consent inbox, where the owner can publish it, return it to private, or delete it.

<code>Special:Perspective</code> is unlisted and unauthenticated; its POST path is defended by pingLimiter, a per-token APCu velocity cap, and fail-closed Turnstile. <code>pcp_perspective_invite</code> holds the token-bearing invitations (<code>pvi_max_uses</code> NULL means an unlimited reusable link); <code>pcp_perspective</code> holds the submissions, each with a <code>psp_validity</code> response-quality flag and the <code>psp_consent</code> gate. The client module <code>ext.pharmacopedia.perspective</code> adds the slider readout and progress bar on the invitee form and the confirm steps on the owner inbox.

== Administer assessments to others ==

A registered user (the '''owner''') can send any of the thirteen registered assessment scales to people outside the wiki (the '''respondents'''), collect their results, and follow them over time. Respondents need no account; a one-time invite link is their only credential. The subsystem is built so that, by default, a respondent's results are readable only by the owner, and the owner can additionally choose a zero-knowledge mode in which not even a site administrator can read them.

=== Assessment registry ===

<code>AssessmentRegistry</code> (<code>includes/Assessments/AssessmentRegistry.php</code>) is the single source of truth: an assessment registered there once autopopulates the owner's scale-picker, the respondent take-flow, and the dashboards. Each entry names a scorer class and a '''response model''':

* <code>radio</code>, discrete labelled radio buttons (CATI, CAT-Q, PID-5-BF, NFCS, BPNS, OCI-PCP, WHOQOL-BREF, ASRS)

* <code>slider</code>, one continuous slider per item with uniform end anchors (OCEAN, Enneagram, AMAAS, HYD-PCP)

* <code>bipolar</code>, one slider per item with the item's own two opposing phrases as the anchors (MBTI)

Every take-flow item also carries a "Not sure" control that disables the item.

=== The four surfaces ===

* '''Entry point''', a control that opens the feature.

* '''Owner hub''' (<code>Special:AdministerAssessments</code>): the owner manages respondents (a named contact list), composes a send (a respondent plus one or more scales), generates a one-time link, and reviews each respondent's results over time. The owner can delete an invite.

* '''Respondent take-flow''' (<code>Special:RespondToAssessment/<token></code>), reached only by the invite link: a consent screen, then the model-aware item forms; once every scale is done the same URL becomes a revisitable results dashboard. Either party can delete.

* '''Key setup''', where the owner chooses how their results are protected (see below).

=== Cryptography ===

Each owner has an '''X25519 keypair'''. The public key is stored in the clear; the secret key is wrapped at rest. A respondent submits while the owner is absent, so the result is sealed to the owner's public key with <code>crypto_box_seal</code>, which needs only the public key; only the owner's secret key can open it. Two protection modes:

* '''Managed''' (default, seamless): the secret key is wrapped with a server master key held in a file outside the web root, never in the database. No passphrase to remember, and a forgotten site password never costs the owner their data. A site administrator could technically read results.

* '''Passphrase''' (opt-in, zero-knowledge): the secret key is wrapped with an Argon2id-derived key from a passphrase only the owner knows. Not even the site can read the results. '''The passphrase cannot be recovered or reset'''; losing it makes every collected result permanently unreadable.

AES-256-GCM is used for key wrapping in both modes. <code>AdminCrypto</code> (<code>includes/Assessments/AdminCrypto.php</code>) is the helper: <code>setupOwnerKey</code>, <code>verifyPassphrase</code>, <code>unlockSecretKey</code>, <code>encryptForOwner</code> / <code>decryptForOwner</code>, <code>encryptForRespondent</code> / <code>decryptForRespondent</code>, <code>mintInviteToken</code> / <code>hashInviteToken</code>. Invite tokens are 256-bit; only their SHA-256 hash is stored, so a stolen database yields no usable tokens. The respondent's own copy of each result is sealed to a key derived from the raw invite token, so the link doubles as the respondent's read credential. A scheme-version column on the key and result rows lets the cipher or KDF be revised over time; the Mode A passphrase KDF currently runs at scheme v2 (Argon2id at MODERATE limits), and an owner created under an earlier scheme is transparently re-wrapped on their next unlock.

=== De-identified research pool ===

Each submission also writes one row to <code>pcp_administer_research</code>, decoupled from the result write, with no foreign key to the invite, respondent, or owner. <code>res_id</code> is a random 128-bit value (not sequential) and the only time field is <code>res_month</code> ('YYYY-MM', no day), so a research row cannot be time-correlated or rank-correlated back to the owner-side tables. The payload is the plaintext item responses plus the computed score. Deleting an invite removes the owner-sealed and respondent-sealed result copies but intentionally leaves the de-identified research row, as the consent screen states.

=== Tables ===

* <code>pcp_administer_respondents</code>, an owner's named contacts (the label is sealed to the owner's public key, so the roster is readable only by the owner)

* <code>pcp_administer_invites</code>, one token-bearing link per send (stores only the SHA-256 of the token)

* <code>pcp_administer_assessments</code>, the scale(s) inside an invite, each with the owner-sealed (<code>aa_payload_enc</code>) and respondent-sealed (<code>aa_respondent_enc</code>) result copies

* <code>pcp_administer_userkey</code>, per-owner key material (public key, wrapped secret key, Mode-A salt and verifier)

* <code>pcp_administer_research</code>, the de-identified research pool

The 13-instrument submission handler reuses the existing assessment scorers in <code>includes/Assessments/</code> rather than reimplementing scoring.

== Choice / multi voting ==

The <code><vote></code> tag's binary up/down mode is unchanged. With <code>type="single"</code> or <code>type="multi"</code> + <code>options="A; B; C"</code> (2-5 entries, semicolon separator), it renders a compact chart-icon chip that expands inline to a radio (single) or checkbox (multi) picker with per-option count bars.

Server-side storage:

* <code>pcp_votable_elements.ve_options</code> (JSON array of labels)

* <code>pcp_votable_elements.ve_options_h</code> (first 8 hex of sha256; drift hash)

* <code>pcp_votable_elements.ve_results_policy</code> (live / after-vote / hidden)

* <code>pcp_votes.v_choices</code> (CSV indices)

* <code>pcp_votes.v_options_h</code> (drift hash at vote time)

API route: same <code>pharmacopediavote</code> endpoint; presence of <code>choices</code> or <code>options_h</code> params routes to <code>castChoice()</code>. Response includes <code>tally</code> + <code>user_choices</code> (null for binary). Tally hidden per <code>results</code> policy.

Drift behavior: if the page editor changes the options list after votes exist, <code>ve_options_h</code> updates and new votes' <code>v_options_h</code> reflects the new value. Existing votes stay but their hash no longer matches (marked stale). New votes whose submitted hash mismatches the live one are rejected, protects against browser cache races. Tallies still aggregate by raw index, so RENAMING an option in place silently turns old votes into new-label votes; reordering is the dangerous case. Appending new options is safe.

== Research ID ==

Every user profile carries a '''research_id''': a 10-character hex string (<code>bin2hex(random_bytes(5))</code> = 40 bits), generated once at profile create, stored UNIQUE in <code>pcp_user_profiles.prof_research_id</code>, and never reassigned.

Purpose: provides a stable opaque identifier for de-identified research participation. It does not reveal the user's wiki username, user_id, or HMAC voter_hash; it survives username changes; and it stays constant across the user's lifetime on the wiki. Users can find theirs in the '''Public identity''' fieldset on <code>Special:MyProfile</code> (single-click to select-and-copy).

Backfilled retroactively for all pre-existing profiles on 2026-05-18 (v0.9.4).

== ClamAV scan rule (project standard) ==

Hard rule, set 2026-05-17: every server-accepted file upload (image, PDF, document, anything) MUST go through <code>VirusScanner::scanFile($path)</code> (<code>includes/VirusScanner.php</code>) BEFORE being moved to permanent storage. Fail-closed: if <code>/usr/bin/clamdscan</code> is unavailable or returns error, the upload is rejected.

Wired into:

* <code>LifeStoryStore::addImage()</code>, life events / episodes / observations

* <code>LiteratureStore::storeUploadedPdf()</code>, literature PDFs

* <code>ProviderAppStore::saveUploadedFile()</code>, provider verification documents

<code>AttachmentScanner</code> (used by feature-request attachments) is left alone, its status-return model is intentional for the queued-moderation flow there. <code>AntivirusHelper</code> (the old silent-no-op variant) was deleted; all callers consolidated onto <code>VirusScanner</code>.

== Autosave infrastructure ==

The save-status indicator is a single colored dot (amber = saving, green = saved, red = error) reparented to <code>document.body</code> and pinned to the top-right corner of whichever form control was last manipulated. Position recomputes on scroll + resize so the dot stays on its anchor through the full pending → saving → ✓ saved cycle.

Every block on <code>Special:MyProfile</code> is wrapped in <code><div data-pcp-save-block="block-name"></code>. The blocksave.js library:

Line 223:

Line 770:

Slider numbers are also clickable: a single delegated handler on every <code><output></code> next to a range slider swaps it for a number input on click, accepts a precise typed value (clamps to the slider's <code>min</code>/<code>max</code>), commits with Enter, cancels with Escape.

Scroll position is preserved across the rare reloads (delete operations on diagnoses / medicines / experience reports, and the auto-reload after a new diagnosis or medicine is added) via <code>sessionStorage</code>.

Scroll position is preserved across the rare reloads (delete operations on diagnoses / medicines / experience reports, and the auto-reload after a new diagnosis or medicine is added) via <code>sessionStorage</code> (the <code>ext.pharmacopedia.bounceback</code> module).

== Editor tools ==

Three contributor-facing tools loaded as <code>ext.pharmacopedia.editor</code> on <code>action=edit</code> and <code>action=submit</code> via <code>Hooks::onBeforePageDisplay()</code>.

=== Smart paste ===

When the clipboard contents on paste is a bare PMID (7-8 digits) or DOI (<code>10.xxxx/...</code>), the module intercepts and expands it to a formatted <code><ref></code> tag. PubMed eutils resolves PMIDs; CrossRef resolves DOIs. Expansion is structured (author, year, title, journal, vol/issue, pages, doi/pmid). A brief toast confirms the substitution; the original paste is preserved if either API call fails.

=== House-rules linter ===

On form submit, the linter strips <code><ref></code> blocks and HTML comments to avoid false positives, then scans the remaining edit body for banned terms (<code>drug</code>, <code>medication</code>, <code>antipsychotic</code>, <code>stimulant</code>) and em-dashes. When matches surface, a non-modal warning panel highlights the offending lines and offers "Save anyway" or "Go back and edit." House rules are advisory, never blocking; the linter is a friction layer that nudges, not a gate.

=== Quick-ref stub ===

<code>Ctrl+Alt+R</code> inserts a <code><ref name="...">{{cite journal | author= ... | year= ... | title= ... | journal= ... | volume= ... | pages= ... | pmid= ... | doi= ... }}</ref></code> skeleton at the cursor, with the cursor positioned at the <code>author=</code> field for direct typing.

== Special pages ==

Line 230:

Line 793:

! Page !! Purpose

|-

| <code>Special:MyProfile</code> || Edit your full profile (identity, demographics, personality, dx, meds). Autosave throughout.

| <code>Special:MyProfile</code> || Edit your full profile (identity, demographics, personality, dx, meds). Autosave throughout. Privacy mode toggle + share chips per fieldset.

|-

| <code>Special:UserProfile/<name></code> || Public profile view (filtered by per-field visibility)

| <code>Special:UserProfile/<name></code> || Public profile view (filtered by per-field visibility + rule-based access). 🔗 Share chip in subtitle for self-view.

|-

| <code>Special:MyAssessment</code> || Index of rich assessment reports

|-

| <code>Special:MyAssessment/cati</code>, <code>/catq</code>, <code>/pid5bf</code>, <code>/mbti</code>, <code>/enneagram</code>, <code>/ocean</code> || Rich report per assessment

| <code>Special:MyAssessment/cati</code>, <code>/catq</code>, <code>/pid5bf</code>, <code>/mbti</code>, <code>/enneagram</code>, <code>/ocean</code> || Rich report per assessment; 🔗 Share chip in subtitle for owner

|-

| <code>Special:TakeAssessment/<key></code> || Generic paginated self-assessment runner; stores raw items and computes scores

|-

| <code>Special:MyLifeStory</code> || Owner editor + visual timeline + card list. Quick-add observation textarea + Event/Episode buttons. 🔗 Share chip in subtitle. Privacy-mode + free-text-refs banners.

|-

| <code>Special:MyLifeStory/add-episode</code>, <code>/edit-episode/<id></code> || Episode form (create / edit)

|-

| <code>Special:MyLifeStory/edit-observation/<id></code> || Observation edit form (re-parses raw text)

|-

| <code>Special:LifeStory/<name></code> || Public life-story view (read-only, visibility-filtered)

|-

| <code>Special:LifeImage</code> || Visibility-gated image streamer for life-story event images

|-

| <code>Special:MyCohorts</code> || Owner-managed groups for share-with-cohort flows; create / rename / delete / add+remove members

|-

| <code>Special:MyShareLog</code> || Who has viewed your shared content (timestamp, viewer, namespace, rule id; anonymous IPs masked)

|-

| <code>Special:MyRefLinks</code> || Bulk linker: find free-text refs in observations that now match a structured entity; one-click upgrade or dismiss

|-

| <code>Special:MyPerspectives</code> || Owner: mint observer-perspective invite links and review the consent inbox

|-

| <code>Special:Perspective/<token></code> || Public, token-gated observer-perspective form (no account; unlisted, anti-abuse defended)

|-

| <code>Special:AdministerAssessments</code> || Owner hub: send assessment scales to outside respondents and follow their results

|-

| <code>Special:RespondToAssessment/<token></code> || Token-gated respondent take-flow and revisitable results dashboard

|-

| <code>Special:SaveProfileBlock</code> || AJAX endpoint for autosave (POST-only, JSON response)

Line 244:

Line 833:

| <code>Special:Problem/<slug></code> || Individual problem page

|-

| <code>Special:SuggestProblem</code> || User-facing form to suggest a new problem

| <code>Special:SuggestProblem</code> || User-facing form to suggest a new problem (page-tied or standalone)

|-

| <code>Special:SuggestAnecdote</code> || Logged-in users propose an anecdote for a medicine page

|-

| <code>Special:SuggestEffect</code> || Logged-in users propose an effect for a medicine page

|-

| <code>Special:SuggestTitration</code> || Logged-in users propose a titration schedule for a medicine page

|-

| <code>Special:ManageProblems</code> || Sysop tool for problem-repository moderation

|-

| <code>Special:~~ReviewExperience~~</code> || Sysop ~~queue~~ for ~~pending experience reports~~

| <code>Special:ManageEffects</code> || Sysop CRUD for the global effects vocabulary

|-

| <code>Special:ManageInteractions</code> || Sysop bulk-edit interaction reports

|-

| <code>Special:ReviewExperience</code> || Sysop queue for pending experience reports

|-

| <code>Special:DeletePharmaElement</code> || Sysop delete tool for any votable element

|-

| <code>Special:VerifyProvider</code> || User-facing form to apply for provider verification and check status

|-

| <code>Special:ProviderApplications</code> || Sysop queue to approve / reject provider-verification applications

|-

| <code>Special:VerificationDoc</code> || Permission-gated streamer for provider-verification document files

|-

| <code>Special:FeatureRequests</code> || User-facing feature-request board (submit and browse)

|-

| <code>Special:RequestReview</code> || Sysop feature-request review console (status counters, prioritized queue, triage)

|-

| <code>Special:LiteratureDoc</code> || Download proxy for approved literature PDFs (reviewers may preview pending)

|-

| <code>Special:LiteratureQueue</code> || Sysop literature review queue (approve / reject / delete)

|-

| <code>Special:PharmacopediaActivity</code> || Recent-activity feed: last 30 votes, effect reports, comments, literature submissions

|-

| <code>Special:NewUsers</code> || The 20 most recently registered accounts

|-

| <code>Special:ProfileAnalysis</code> || Sysop dashboard of cross-table profile aggregates; per-section CSV export

|-

| <code>Special:ProfileFilter</code> || Sysop cross-filter UI over user profiles (demographics, OCEAN ranges, dx, med); CSV export

|-

| <code>Special:PCPCtrls</code> || Sysop controls hub (gated by <code>$wgSpecialPageLockdown</code>)

|-

| <code>Special:AdminCtrls</code> || Admin-controls landing page (renders sysop-editable <code>MediaWiki:Adminctrls-body</code>)

|-

| <code>Special:DatePickerTest</code> || Developer sandbox exercising the date-input widget (point / range / possibility)

|}

Line 260:

Line 885:

! Action !! Purpose

|-

| <code>pharmacopediavote</code> || ~~Submit~~ / ~~clear binary~~ vote ~~on votable element~~

| <code>pharmacopediavote</code> || Binary OR choice/multi vote (routes by presence of <code>choices</code> param). Returns tally + user_choices for choice modes; gated by results-policy.

|-

| <code>pharmacopedialikert</code> || Submit problem-efficacy likert (0–100 + −1 DK)

Line 280:

Line 905:

| <code>pharmacopediaproblemsearch</code> || Problem-repository autocomplete

|-

| <code>pharmacopediaeffectslookup~~</code>, <code>indicationslookup~~</code> || ~~Pickers~~ used by the experience-submit form

| <code>pharmacopediaeffectslookup</code> || Picker used by the experience-submit form

|-

| <code>pharmacopedialiteratureadd</code>, <code>literaturedelete</code> || Literature attachment ops

|-

| <code>pharmacopediaobservation</code> || op=preview / op=submit for plain-text observations (routes to addObservation OR addEpisode)

|-

| <code>pharmacopediavisrules</code> || Visibility rule CRUD (list / create / update / revoke / newtoken)

|-

| <code>pharmacopediausersearch</code> || Username autocomplete for share-with-people picker

|-

| <code>pharmacopediacohorts</code> || Cohort CRUD + membership

|-

| <code>pharmacopediarefupgrade</code> || Free-text ref linker (op=candidates / apply / dismiss)

|-

| <code>pharmacopediaformaltest</code> || Formal-testing score operations (list / add / update / delete), with per-field visibility

|}

Line 321:

Line 958:

* Efficacy (0–100 slider)

* Side-effect burden (0–100 slider)

* Stop reasons (personal + stopped only): JSON multi-select with optional severity slider per reason — codes: side_effects / ineffective / cost / no_longer_needed / clinician_advised / other

* Stop reasons (personal + stopped only): JSON multi-select with optional severity slider per reason, codes: side_effects / ineffective / cost / no_longer_needed / clinician_advised / other

* Free-text anecdote

* Problems addressed (multi-pick with per-problem efficacy)

Line 331:

Line 968:

! Table !! Purpose

|-

| <code>pcp_votable_elements</code> || Stable per-(page, slug) handle reused by votes / likert / comments

| <code>pcp_votable_elements</code> || Stable per-(page, slug) handle reused by votes / likert / comments. Also <code>ve_options</code> + <code>ve_options_h</code> + <code>ve_results_policy</code> for choice votes.

|-

| <code>pcp_votes</code> || Binary +1/−1 votes

| <code>pcp_votes</code> || Binary +1/−1 votes (v_value) AND choice/multi votes (v_choices CSV + v_options_h drift hash)

|-

| <code>pcp_likert_reports</code> || Problem efficacy (0–100 + −1 DK), TINYINT signed

Line 343:

Line 980:

| <code>pcp_interactions</code> || Interaction edges (canonical-ordered pair)

|-

| <code>pcp_comments</code> || Threaded discussions

| <code>pcp_comments</code> || Threaded <code><discuss></code>-tag discussions (soft-delete, optional display name)

|-

| <code>pcp_user_profiles</code> || Per-user profile meta (alias, attribution, voter hash)

| <code>pcp_user_profiles</code> || Per-user profile meta (alias, attribution, voter hash, prof_research_id)

|-

| <code>~~pcp_user_profile_fields~~</code> || Generic key-value field store: (namespace, key, num, text, visibility)

| <code>pcp_profile_fields</code> || Generic key-value field store: (namespace, key, num, text, visibility)

|-

| <code>pcp_profile_diagnoses</code> || Per-user diagnoses (system, code, description, status, origin, severity 0–100, disability 0–100, dates, notes, visibility)

Line 359:

Line 996:

| <code>pcp_experience_reports</code> || Experience reports (pending → approved); efficacy + burden 0–100; route + schedule; stop-reasons JSON; patient-count min + max

|-

| <code>pcp_life_events</code>, <code>pcp_life_traits</code>, <code>~~pcp_life_images~~</code> || ~~Life Story keyframes~~ (~~auto~~-~~generated from assessments~~, ~~manually authorable~~)

| <code>pcp_life_events</code> || Timeline events. Columns: le_type (0=story, 1=image, 2=keyframe, 3=observation, 4=episode), le_polarity, le_raw_text (parser input), le_episode_type, le_episode_subtype, le_severity, le_date_struct (PCPDatePicker JSON; supports range)

|-

| <code>pcp_life_event_refs</code> || Join table linking events to entities (med / effect / problem / diagnosis / med_page / diagnosis_code / free); role (subject / cause / context / symptom / trigger / treatment)

|-

| <code>pcp_life_traits</code> || Keyframe trait values (assessment subscale snapshots → trajectory graph)

|-

| <code>pcp_life_images</code> || Image attachments (ClamAV-scanned)

|-

| <code>pcp_visibility_rules</code> || Per-(profile, namespace, key) sharing rules. Types: public / private / users / cohort / link_token / reciprocal. Optional vr_expires, vr_revoked, vr_attribution, vr_label.

|-

| <code>pcp_cohorts</code>, <code>pcp_cohort_members</code> || Owner-managed user groups for share-with-cohort flows

|-

| <code>pcp_visibility_view_log</code> || Audit trail of rule-permitted views (Special:MyShareLog)

|-

| <code>pcp_perspective_invite</code> || Token-bearing observer-perspective invitations (display name, object, type, max-uses)

|-

| <code>pcp_perspective</code> || Submitted observer perspectives (payload JSON, validity flag, consent gate)

|-

| <code>pcp_literature</code> || ~~Citation~~ attachments

| <code>pcp_administer_respondents</code> || An owner's named contacts; the label is sealed to the owner's public key

|-

| <code>pcp_administer_invites</code> || One token-bearing administer link per send; stores only SHA-256 of the token

|-

| <code>pcp_administer_assessments</code> || The scale(s) in an invite; owner-sealed and respondent-sealed result copies

|-

| <code>pcp_administer_userkey</code> || Per-owner key material (X25519 public key, wrapped secret key, Mode-A salt + verifier)

|-

| <code>pcp_administer_research</code> || De-identified research pool: random id, coarsened month, no link back to the owner

|-

| <code>pcp_provider_apps</code> || Provider-verification applications (profession, specialty, jurisdiction, license, status, doc paths)

|-

| <code>pcp_literature</code> || Per-page literature submissions (citation metadata, optional PDF, status, reviewer)

|-

| <code>pcp_feature_request</code>, <code>pcp_feature_request_attachment</code>, <code>pcp_feature_request_comment</code> || Feature-request board: requests, ClamAV-scanned attachments, threaded comments

|-

| <code>pcp_formal_tests</code> || Catalog of standardized tests (abbrev, full name, category, score format)

|-

| <code>pcp_user_test_scores</code> || Per-user formal-test scores; raw score / percentile / pass-fail, each with its own visibility (uts_vis_raw / uts_vis_pct / uts_vis_passfail) and an estimate flag

|}

== Notable lessons learned ==

* '''Cargo string fields cap at ~300 chars.''' <code>structure</code> and <code>mechanism</code> on MedTemplate are short VARCHARs; long prose goes in MEDIUMBLOB sections ~~(pharmacokinetics, pharmacodynamics, intro)~~. Overruns silently lose Cargo data (MySQL Error 1406).

* '''Synthetic Event needs bubbles:true to trigger delegated listeners.''' <code>new Event('input')</code> defaults to <code>bubbles:false</code>, so listeners on parent wrappers never see programmatic dispatches. Native input/change events bubble by default; only JS-fired ones don't. Pass <code>{ bubbles: true }</code> explicitly. Bit DatePicker calendar-cell clicks 2026-05-18, typing in the text field autosaved fine, but picking a date from the calendar didn't, because blocksave's wrapper listener never received the event.

* '''VARBINARY + LOWER() is a no-op.''' MariaDB's LOWER() returns binary types unchanged. <code>pcp_diagnosis_abbreviations</code> was migrated VARBINARY → VARCHAR/utf8mb4 ~~(2026-05-17)~~ so case-insensitive LIKE works natively without CONVERT() wrappers.

* '''MediaWiki form-field names collide with reserved URL params.''' A form <code><input name="title"></code> or <code>name="action"></code> with user-controlled value silently HIJACKS MW's dispatch when POSTed (body param overrides URL param). Symptom: form submits but lands on a wiki article named whatever the user typed, with URL bar still showing the special page. Bit the episode form 2026-05-18 (user typed 'Fake one' as title → got a 404 'create article: Fake one' page). Fix: prefix ALL custom form inputs with <code>pcp_</code> (both the input <code>name="..."</code> AND the matching <code>$request->getVal('...', ...)</code> read). Self-referential hidden inputs (<code>name="title" value="<getPageTitle()>"</code>) are safe.

* '''FlaggedRevs locks template inclusions by default.''' Config fix: <code>$wgFlaggedRevsHandleIncludes=0</code> + remove NS_TEMPLATE from <code>$wgFlaggedRevsNamespaces</code> via an extension-function callback ~~(MW 1.46 array config concatenation behavior)~~.

* '''Cargo string fields cap at ~300 chars.''' <code>structure</code> and <code>mechanism</code> on MedTemplate are short VARCHARs; long prose goes in MEDIUMBLOB sections. Overruns silently lose Cargo data (MySQL Error 1406).

* '''CSP must allow Cloudflare Turnstile and any other 3rd-party widget script source.''' ~~Symptom: generic "There are problems with some of your input" on form submit.~~ Audit script-src / frame-src / connect-src / style-src whenever adding any 3rd-party JS widget.

* '''VARBINARY + LOWER() is a no-op.''' MariaDB's LOWER() returns binary types unchanged. <code>pcp_diagnosis_abbreviations</code> was migrated VARBINARY → VARCHAR/utf8mb4 so case-insensitive LIKE works natively without CONVERT() wrappers.

* '''Sidebar cache must be purged after CLI <code>maintenance/edit.php</code> writes''' to <code>MediaWiki:Sidebar</code> or other chrome pages: <code>~~curl~~ -~~X POST~~ .../~~api~~.~~php?action~~=~~purge~~&~~titles=~~MediaWiki~~:Sidebar~~</code>.

* '''FlaggedRevs locks template inclusions by default.''' Config fix: <code>$wgFlaggedRevsHandleIncludes=0</code> + remove NS_TEMPLATE from <code>$wgFlaggedRevsNamespaces</code> via an extension-function callback.

* '''~~CLI E_USER_DEPRECATED suppressed in LocalSettings~~.~~php~~''' (~~EmbedVideo / FlaggedRevs spam ~6~~ lines per ~~maintenance/run~~.~~php call on MW 1~~.~~46)~~. ~~Web behavior unaffected~~.

* '''CSP must allow Cloudflare Turnstile and any other 3rd-party widget script source.''' Audit script-src / frame-src / connect-src / style-src whenever adding any 3rd-party JS widget.

* '''Sidebar cache must be purged after CLI <code>maintenance/edit.php</code> writes''' to <code>MediaWiki:Sidebar</code> or other chrome pages.

* '''CLI E_USER_DEPRECATED suppressed in LocalSettings.php''' (EmbedVideo / FlaggedRevs spam on MW 1.46). Web behavior unaffected.

* '''MW ApiResult drops keys starting with <code>_</code>.''' Any field whose key starts with underscore in an ApiResult payload is treated as internal metadata and stripped. Rename to plain identifier. Bit Phase 2-4 of visibility-rules subsystem.

* '''MW API serializes int-keyed assoc arrays unreliably.''' <code>[23 => 'Alice']</code> may arrive as <code>{"23": "Alice"}</code> or worse. Always use list-of-objects (<code>[{"id": 23, "name": "Alice"}]</code>) for id-to-value maps across the API boundary.

* '''PHP single-quoted strings don't interpret <code>\xNN</code> byte escapes.''' <code>'\xF0\x9F\x94\x97'</code> is 16 literal chars, NOT the 4-byte UTF-8 for 🔗. Use literal Unicode char or double-quoted <code>\u{1F517}</code>. Bit three times in one session.

* '''PHP "0" is FALSY.''' <code>!"0"</code> evaluates to TRUE. So <code>if ( !$x )</code> silently treats <code>"0"</code> (string zero) as missing. Bit choice-vote tallying when voter picked option index 0; vote was IN the DB but invisible to readers. Use <code>=== null || === ''</code> for "missing or blank" intent. <code>empty()</code> has the same problem.

* '''<code><span></code> can't contain <code><p></code>.''' MediaWiki auto-wraps tag content in <code><p></code> when there are newlines; browsers auto-close any <code><span></code> before the <code><p></code>, scattering child elements into wrong DOM positions. Use <code><div></code> for parser-tag wrappers whose content can span paragraphs (choice votes, life-story cards).

* '''vis.Graph2d group <code>style</code> belongs at TOP LEVEL''' not nested in <code>options</code>. Nesting silently fails (no error, just invisible lines). Bit the trait-trajectory graph on first build.

* '''A symmetric data-key cannot serve an asynchronous flow.''' The administer-to-others result must be encryptable while the owner is absent. A purely symmetric per-owner key has no holder at submission time; the model must be an asymmetric keypair, with the public key stored openly so a sealed box can always be written and only the owner's wrapped secret key can open it.

* '''A de-identified row must carry no order and no link.''' An auto-increment id rank-correlates with the source table and an insert timestamp time-correlates with it. The research pool uses a random 128-bit id and a month-only date so a row genuinely cannot be traced back.

== Hooks ==

Line 377:

Line 1,058:

* <code>ParserFirstCallInit</code>: register all parser tags

* <code>LoadExtensionSchemaUpdates</code>: install / migrate schema (the sql/ directory + patches)

* <code>BeforePageDisplay</code>: inject the ext.pharmacopedia.* ResourceLoader modules

* <code>BeforePageDisplay</code>: inject the ext.pharmacopedia.* ResourceLoader modules; resolve and apply the page skin (the <code>pcp-skin-*</code> body class) and, on the Main Page / Category index, the <code>pcp-diptych-page</code> chromeless class

* <code>UserGetRights</code> + <code>UserEffectiveGroups</code>: verified-provider role wiring

* Various special-page registrations via <code>SpecialPage_initList</code>

== Custom content namespaces ==

Six dedicated content namespaces sit above NS_MAIN for entities that have their own canonical wiki page beyond the main encyclopedic article surface. All are registered with talk pages (id +1), counted as content, included in default search, and tracked by FlaggedRevs (the FlaggedRevs registration is deferred via <code>$wgExtensionFunctions</code> so it runs after the extension's defaults merge, the same timing fix as the original NS_TEMPLATE block).

{| class="wikitable"

! ID !! Namespace !! Purpose

|-

| 3000 / 3001 || Enzyme: / Enzyme talk: || Drug-metabolizing enzymes (CYPs, UGTs, etc.) with locked-template substrate tables

|-

| 3002 / 3003 || Receptor: / Receptor talk: || Receptor entity pages

|-

| 3004 / 3005 || Phenotype: / Phenotype talk: || PGx phenotype reference pages

|-

| 3006 / 3007 || USLegal: / USLegal talk: || US legal / regulatory status reference pages (Prescription only, OTC, DEA Schedule I-V, plus terse redirects)

|-

| 3008 / 3009 || Problem: / Problem talk: || Per-Problem wiki pages; one per <code>pcp_problem</code> row; <code>p_page_id</code> column links the canonical DB row to its page id; <code><problemMedicines slug="X"/></code> auto-emits the medicines list inside each page

|-

| 3010 / 3011 || Effect: / Effect talk: || Per-Effect wiki pages; one per <code>pcp_effects</code> row; <code>e_page_id</code> column links the canonical DB row to its page id; <code><effectMedicines slug="X"/></code> auto-emits the medicines list inside each page

|}

The Problem: and Effect: namespaces ship with 170 + 288 auto-created stub pages (one per non-retired row in the canonical tables), produced by <code>maintenance/migrateProblemEffectStubs.php</code>. Each stub carries a one-line "Stub" header, the canonical description if any, the auto-generated medicines section, and the sentinel <code>Category:Problem stubs</code> / <code>Category:Effect stubs</code> for the buildout queue. The migration script is CLI-only, idempotent on re-run, and credits MDElliottMD via <code>EDIT_INTERNAL</code> (skips AbuseFilter + captcha + rate limits per MW convention for ops migrations).

Inbound linkage: every <code><problem ref="X"></code> on a medicine page links its problem-card title to <code>Problem:<Name></code>; every <code><effect ref="X"></code> links its label to <code>Effect:<Name></code>; the sidebar Common-uses list links the same way. <code>Special:Problem/<slug></code> auto-redirects to the matching NS page when <code>p_page_id</code> is set (the legacy aggregate render stays as a fallback for any unmigrated row).

== Wiki-content pages we maintain ==

Alongside the content articles themselves, the project maintains a small set of canonical wiki-content pages whose state is recorded in this spec doc:

* <code>About:Pharmacopedia.ext</code>: this spec, kept lockstep with extension version (interface-claude updates body + version line on every close-out).

* <code>About:Privacy</code>: site privacy policy, plain-language, covering data collection, third parties (Cloudflare Turnstile + Gmail SMTP + Dropbox-as-encrypted-backup-sub-processor), cookies, retention windows, encryption (Let's Encrypt TLS, PBKDF2-SHA512 passwords, OATHAuth 2FA, AdminCrypto X25519 sealed-box + AES-256-GCM, OAuth 2.0 + PKCE for the iOS app, GPG-AES256 backups), and the manual-today deletion path with the up-to-60-day backup-lag disclosure.

* <code>Category:Pharmaceutical</code> + <code>Category:Plants</code>: the two origin categories; every medicine page belongs to exactly one. Each category page is a descriptive history-first article per the canonical category-page spec.

* The eleven Pendell-class category pages (<code>Category:Euphorica</code>, <code>Category:Evaesthetica</code>, etc.): per-class wiki articles with an opening English-gloss clause sourced from Pendell's trilogy.

* The seven USLegal status pages (<code>USLegal:Prescription only</code>, <code>USLegal:Over-the-counter</code>, <code>USLegal:DEA Schedule I</code>...<code>V</code>) plus 26 terse redirects; medicine pages link these via the MedTemplate <code>legal=</code> field.

* <code>MediaWiki:Sidebar</code>: standard MW sidebar with the local additions (My profile, My assessments, etc.).

== Configuration globals ==

* <code>$wgPharmacopediaInteractionCategoryMarker</code> (default <code>Category:MedCategory</code>): only categories tagged with this marker appear in the add-interaction modal

* <code>$wgPharmacopediaVoteHashSecret</code> (required): HMAC secret for <code>v_voter_hash</code> so vote rows can't be mapped back to user accounts by anyone reading the DB without the secret

* <code>$wgPharmacopediaAdminKeyDir</code>: filesystem directory, outside the web root, holding the administer-to-others server master key (managed mode); never in the database, never in the DB backup set

* (Various permission-grant arrays via standard MW <code>$wgGroupPermissions</code>)

Line 392:

Line 1,110:

|-- includes/

| |-- Hooks.php

| |-- *Tag.php (parser tags: VoteTag, EffectTag, ProblemTag, ...)

| |-- *Tag.php (parser tags: VoteTag, EffectTag, ProblemTag,

| |-- *Store.php (data access: EffectStore, ProblemStore, ...)

| | ClassGridTag, ClassTreeTag, LiteratureTag,

| | FrontPageTag, CategoryIndexTag, ...)

| |-- DiptychChrome.php (shared topbar + footer for the diptych splashes)

| |-- *Store.php (data access: EffectStore, ProblemStore, ElementStore, LifeStoryStore, ...)

| |-- UserProfileStore.php (the big one; profile / dx / meds / abbreviations)

| |-- VisibilityResolver.php (per-record sharing decision engine)

| |-- VirusScanner.php (ClamAV gate; fail-closed)

| |-- ObservationParser.php (plain-text -> structured observation)

| |-- SpecialMyProfile.php (the user profile editor; large)

| |-- SpecialMyAssessment.php (rich reports for ~~all 6~~ assessments; large)

| |-- SpecialMyAssessment.php (rich reports for the dimensional assessments; large)

| |-- ~~SpecialSaveProfileBlock~~.php (~~autosave AJAX endpoint~~)

| |-- SpecialMyLifeStory.php (life-story editor + visual timeline; large)

| |-- SpecialMyPerspectives.php / SpecialPerspective.php (observer perspectives)

| |-- SpecialAdministerAssessments.php / SpecialRespondToAssessment.php (administer to others)

| |-- SpecialPCPCtrls.php (sysop controls hub)

| |-- Special*.php (other special pages)

| |-- ProfileDatasets.php (countries, languages, genders, religions, etc.)

| |-- DatePicker.php (range / possibility-mix date widget backend)

| |-- DatePicker.php (range / possibility-mix date widget backend + injectBirthdayContextOnce)

| |-- Assessments/

| | |-- AssessmentRegistry.php (single source of truth for the 13 instruments)

| | |-- AdminCrypto.php (X25519 / Argon2id / AES-256-GCM helper)

| | |-- Cati.php, CatiNorms.php

| | |-- Catq.php

| | |-- Catq.php, CatqNorms.php

| | |-- Pid5bf.php

| | |-- Pid5bf.php, Pid5bfNorms.php

| | |-- Mbti.php

| | |-- Enneagram.php

| | |-- Ocean.php, OceanNorms.php

| | |-- Asrs.php, Amaas.php

| | |-- Bpns.php, BpnsNorms.php

| | |-- Nfcs.php, NfcsNorms.php

| | |-- Ocipcp.php

| | |-- WhoqolBref.php, WhoqolBrefNorms.php

| | `-- Raadsr.php (deprecated 2026-05-17 in favor of CATI, kept for archival reads)

| `-- Api/

| `-- ~~(one class per API module)~~

| |-- VoteApi.php, EffectApi.php, ...

| |-- ObservationApi.php

| |-- VisibilityRulesApi.php, UserSearchApi.php, CohortsApi.php

| `-- RefUpgradeApi.php

|-- resources/

| |-- ext.pharmacopedia.js (single IIFE: chip-picker, dx autocomplete, ~~BFI~~-~~10 compute,~~ ...)

| |-- ext.pharmacopedia.js (single IIFE: chip-picker, dx autocomplete, vote logic, ...)

| |-- ext.pharmacopedia.blocksave.js (debounced autosave per block)

| |-- ext.pharmacopedia.styles.css (base stylesheet, self-hosted fonts)

| |-- ext.pharmacopedia.css

| |-- ext.pharmacopedia.blocksave.js (debounced autosave per block)

| |-- ext.pharmacopedia.~~datepicker~~.js + .css

| |-- ext.pharmacopedia.bounceback.js (scroll-position preservation)

| |-- ext.pharmacopedia.confirmdelete.* (styled destructive-action prompt)

| |-- ext.pharmacopedia.datepicker.js + .datepicker.styles.css

| |-- ext.pharmacopedia.timepicker.js + .timepicker.styles.css

| |-- ext.pharmacopedia.share.js + .css

| |-- ext.pharmacopedia.perspective.* (observer-perspective form enhancement)

| |-- ext.pharmacopedia.administer.* (administer-to-others surfaces)

| |-- ext.pharmacopedia.observation.js + .css

| |-- ext.pharmacopedia.refupgrade.js + .css

| |-- ext.pharmacopedia.lifetimeline.js + .css

| |-- ext.pharmacopedia.lifegraph.js + .css

| |-- ext.pharmacopedia.kitsync.js

| |-- ext.pharmacopedia.frontpage.* / ext.pharmacopedia.categoryindex.* (diptych splashes)

| |-- ext.pharmacopedia.appearance.* (the Appearance rail)

| |-- ext.pharmacopedia.skin.plants.css (plants-skin overlay)

| `-- vendor/vis-timeline/ (vis-timeline 7.7.3, Apache-2.0 + MIT)

| |-- vis-timeline-graph2d.min.js

| |-- vis-timeline-graph2d.min.css

| `-- LICENSE

|-- sql/

| |-- (one .sql per table; patches as patch-*.sql)

MDElliottMD (talk | contribs)