PC NET DESK — AGENT REFERENCE
Reviewed: 2026-09-12. Core Console 3.45. Source revision f6df4373df26107233ea68ea5fe8d780486e3751.

READ-ONLY DOCUMENTATION
This document describes the platform. It does not grant authority, supply credentials or execute operations.
Product: https://glasscityi.com/pcnetdesk
Technology: https://glasscityi.com/pcnetdesk/tech
Complete JSON catalog: https://glasscityi.com/pcnetdesk/catalog.json

DESIGN AND IDENTITY
PC NET DESK was created for people and AI agents. It supplies an authorized browser workspace, registered commands, structured CMS data and HTTP operations sharing backend services with supported visual tools. The reviewed source does not bundle an LLM, MCP server, public API-key agent SDK or autonomous planner. An external agent adapter requires implemented authentication and approved tool mapping.
Administrative paths belong to https://www.pc-net-techs.com, not the documentation site. Use an authorized member session and comply with endpoint permissions, configured passkey requirements and lock checks.

COMMAND CONTRACT
POST /api/cc/console
Content-Type: application/json
Body: {"command":"tasks"}
One fixed-vocabulary command per request. Double quotes group arguments with spaces. Keep input within 500 characters; the server truncates longer input. This is not a shell.
Response: {"ok":true,"lines":["..."],"isError":false}
HTTP 200 and ok:true may accompany isError:true. Inspect HTTP status, ok, isError and output. Invalid JSON returns 400; missing sign-in or required passkey verification 401; unauthorized membership 403.

READ, ACT, VERIFY
1. Discover syntax with help and help <command>.
2. Read current records and obtain actual IDs. Identify target and live/draft/published scope.
3. Choose one authorized operation. Review creates, replacements, deletion, approvals, access changes and publication.
4. Inspect errors and output, then re-read the affected record or page.
5. Inspect current state before retrying an ambiguous timeout: the write may already have succeeded.

OPERATIONAL DETAILS
note set replaces the shared note. task undone reopens a completed task; task rm removes it. calendar lists events; gallery lists image URLs. Their other operations use their visual/HTTP tools.
actions run can change already-due website settings. lock and actions apply subcommand-specific gates although their registry mutation flags are false. alerts, passkeys and security are marked mutating at family level, including their listing forms. Individual operations have distinct permissions. Shared middleware adds configured passkey verification when a Wix member is present; ceremony, verification and recovery routes have explicit exceptions. Route membership and operation checks still apply.
approve and reject record decisions; they do not automatically publish or undo a website. Access/command logging is best effort on implemented paths, not a transactional audit of every operation.

BUILDER, STYLE AND SCHEDULES
The base schema contains 124 fields in ten sections. Ten component groups define field types and item limits; dynamic items add field IDs. Product cards support 1–8 nested bullets. Six middle sections may be reordered between Hero and Contact.
Content, structure, style and logo are separate state layers. Draft scope is authorized per request and stored in Astro.locals. Publishing writes four target-specific snapshots, then a registry entry, at /published/<slug>. It does not replace the main homepage. A slug is 1–32 lowercase letters, digits or hyphens with alphanumeric boundaries; foreign hosts, nested paths and reserved names are rejected.
Publishing is not an atomic four-record transaction. New targets remain unavailable by route until registered; existing targets may be partially replaced after an error. Inspect all layers before retrying. Text reset does not restore structure.
The resolved Themes object contains 133 properties including derived outputs; it is not a list of independently writable API fields. Website, Console, Desk and Builder expose their supported subsets. The scheduler exposes 32 fields with validated enum, boolean, 0–100, hex-color or cursor-mode values.
Due actions are checked during rendering with a one-minute per-instance throttle and a 15-minute heartbeat. Execution is best effort, not exact-second or distributed exactly-once. Emergency Lock suppresses changes. A separate action restores a temporary value. Builder publication is separate.

INTERPRETING REPORTING
Reporting is described in the connected configuration at the owner’s direction. IP/company/location estimates do not prove a named person’s identity. Referrers may be missing. Engagement time differs from elapsed page-to-page time; clicks differ from forms and provider-recorded calls. Intent is inferred unless explicitly supplied. Public competitor research does not expose private visitor identities or sessions. AI crawler activity differs from an AI-referred human visit.

DEPENDENCIES
@simplewebauthn/server: locked 13.3.2; declared ^13.3.2; dependencies. Generates and verifies WebAuthn registration/authentication challenges.
@wix/astro: locked 2.63.0; declared ^2.63.0; dependencies. Connects the Astro application to Wix headless services and tooling.
@wix/astro-pages: locked 2.0.4; declared ^2.0.4; dependencies. Integrates Wix page handling with Astro.
@wix/dashboard: locked 1.3.45; declared ^1.3.36; dependencies. Installed Wix dashboard integration package; the reviewed application source has no direct import.
@wix/data: locked 1.0.480; declared ^1.0.480; dependencies. Provides collection queries and writes for persistent records.
@wix/essentials: locked 1.0.8; declared ^1.0.6; dependencies. Supplies server-side elevation and authenticated service calls used by the Wix helper and CMS stores.
@wix/media: locked 1.0.259; declared ^1.0.0; dependencies. Supplies managed media upload and file-service operations.
@wix/members: locked 1.0.481; declared ^1.0.481; dependencies. Supplies member identity and account preparation operations.
@wix/sdk: locked 1.21.12; declared ^1.21.5; dependencies. Provides the shared Wix SDK/client layer.
astro: locked 5.18.2; declared ^5.8.0; dependencies. Renders application pages/components and supplies file-based API routing.
typescript: locked 5.9.3; declared ^5.8.3; dependencies. Checks typed application code and registry contracts.
@astrojs/check: locked 0.9.9; declared ^0.9.9; devDependencies. Runs Astro component diagnostics in the validation workflow.
@astrojs/cloudflare: locked 12.6.13; declared ^12.5.3; devDependencies. Installed alternative adapter; the reviewed configuration selects the Wix cloud-provider Fetch adapter.
@astrojs/react: locked 4.4.2; declared ^4.3.0; devDependencies. Enables React components in Astro when required.
@types/react: locked 18.3.31; declared ^18.3.1; devDependencies. Provides React TypeScript declarations.
@types/react-dom: locked 18.3.7; declared ^18.3.1; devDependencies. Provides React DOM TypeScript declarations.
@wix/cli: locked 1.1.226; declared ^1.1.226; devDependencies. Runs Wix development, build, preview, release and related commands.
@wix/cloud-provider-fetch-adapter: locked 1.0.4; declared ^1.0.0; devDependencies. The selected production adapter for the Wix-managed Fetch-compatible runtime.
react: locked 18.3.1; declared 18.3.1; devDependencies. Installed component runtime available through the Astro React integration.
react-dom: locked 18.3.1; declared 18.3.1; devDependencies. Provides the rendering layer for React components.

COMMAND REGISTRY
help: List all commands, or show usage for one.
Syntax: help [command]
Behavior: Read / inspect. Start with help, then help <command>. Syntax is a fixed command vocabulary, with double quotes for arguments containing spaces.

version: Core Console / PC NET DESK version.
Syntax: version
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

whoami: Current signed-in member and admin status.
Syntax: whoami
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

date: Current date/time (Eastern).
Syntax: date
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

echo: Print text back.
Syntax: echo <text>
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

status: Combined system status: lock, passkeys, heartbeat.
Syntax: status
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

heartbeat: Actions heartbeat detail.
Syntax: heartbeat
Behavior: Read / inspect. Reads heartbeat timing and counts; it does not run a resident background worker.

lock: Emergency Lock status and control.
Syntax: lock status | lock enable [reason] | lock disable <phrase>
Behavior: Mixed / inspect subcommand. Mixed read/write family. Each subcommand applies its own rules; the registry-wide mutates flag is false. Recovery uses a separately held secret.

tasks: List tasks.
Syntax: tasks
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

task: Manage tasks.
Syntax: task add "<title>" ["<impact>"] | task done <id> | task undone <id> | task rm <id>
Behavior: Changes records. add creates a task; done and undone change status; rm removes the selected record. Read tasks to obtain the current ID.

notes: Show the shared notes.
Syntax: notes
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

note: Replace the shared notes content.
Syntax: note set "<content>"
Behavior: Changes records. set replaces the shared note content. Read notes first to avoid overwriting information unintentionally.

changelog: Show the last n changelog entries (default 10).
Syntax: changelog [n]
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

approvals: List approvals.
Syntax: approvals
Behavior: Read / inspect. Uses the authorized command context and the registered handler. Inspect the result and verify any affected state.

approve: Mark an approval approved.
Syntax: approve <id>
Behavior: Changes records. Records an approval decision for the chosen item. It does not automatically publish a Builder page.

reject: Mark an approval rejected.
Syntax: reject <id>
Behavior: Changes records. Records a rejection decision for the chosen item. It does not undo a previously deployed change.

access: Recent access log, grouped by IP (default 10 groups).
Syntax: access [n]
Behavior: Read / inspect. Reads grouped access history with recorded outcomes. Availability depends on what each access path records.

visitors: Last n distinct-IP website visits (default 5).
Syntax: visitors [n]
Behavior: Read / inspect. Lists recent distinct-IP visits. An IP-grouped record is not proof of a named person’s identity.

calls: Call stats (CallRail if connected, otherwise sample data).
Syntax: calls
Behavior: Read / inspect. Reads the configured call-tracking feed. A call record and a click on a telephone link represent different events.

calendar: List calendar events (read-only — add/edit via the Calendar app).
Syntax: calendar
Behavior: Read / inspect. This command lists calendar events. Create and edit events through the visual app or its separate endpoint.

gallery: List gallery image URLs (read-only — the picker grid is visual).
Syntax: gallery
Behavior: Read / inspect. Returns gallery image URLs. Uploading, selecting and camera capture use the visual/media workflow.

actions: Scheduled Actions: list, run due actions now, or show valid fields.
Syntax: actions [list|run|fields]
Behavior: Mixed / inspect subcommand. list reads schedules; fields lists schedulable settings; run applies already-due work and changes state. run checks its lock gate inline.

alerts: Unacknowledged security alerts, or acknowledge all (admin only).
Syntax: alerts [ack]
Behavior: Mixed / inspect subcommand · Admin. Admin-only. The entire family is marked as mutating, including the listing form. ack acknowledges alerts.

passkeys: List/rename/revoke your passkeys; admin can toggle enforcement.
Syntax: passkeys [list] | passkeys rename <id> <name> | passkeys revoke <id> | passkeys enforce on|off
Behavior: Mixed / inspect subcommand. Management operates on authorized passkeys; enforcement is admin-only. The entire family is marked as mutating, including list.

forms: Recent website form submissions (default 10; 'new' filters to unworked).
Syntax: forms [n] | forms new
Behavior: Read / inspect. Reads submissions, with an optional limit or the new-only filter. Form records include contact details and should stay within authorized reporting.

form: Work a submission: set status or replace its notes.
Syntax: form status <id> new|contacted|closed | form note <id> "<text>"
Behavior: Changes records. Changes one record’s status or note. Status is one of new, contacted, or closed.

security: Security settings — admin only.
Syntax: security [show] | security ip add|rm <ip> | security ip on|off | security notify on|off
Behavior: Mixed / inspect subcommand · Admin. Admin-only. Lists or changes configured IP, notification and security settings. The family is marked as mutating even for show.

API ROUTES
GET/POST /api/cc/actions-run: Run already-due website actions
Contract: GET or POST with no input; returns ok, ran and, when applicable, locked.
Access: Public by design; cannot create an action or accept an arbitrary setting. Emergency Lock suppresses execution.

GET/POST /api/cc/actions: List and maintain schedules
Contract: GET lists; POST accepts add, update, or deleteId. An action has name, field, value, runAt, repeatKind, and enabled.
Access: Authorized member for access; writes apply the endpoint’s lock gate. Values come from FIELD_DEFS.

POST /api/cc/calendar: Maintain calendar records
Contract: POST accepts add, update (including id), or deleteId.
Access: Authorized member and mutation lock checks; calendar command is a separate read path.

POST /api/cc/console: Execute a registered command
Contract: POST { command: string }; returns lines and isError alongside ok.
Access: Explicitly authorized member; configured passkey enforcement; additional command-level authorization and lock handling.

GET/POST /api/cc/emergency-lock: Inspect, enable and recover the lock
Contract: GET reads state. POST action enable records a reason; action disable supplies the recovery credential.
Access: Enable uses administrative membership. Recovery deliberately has a distinct credential-based path.

POST /api/cc/forms: Review and update contact submissions
Contract: POST action list; action status with id and status; action notes with id and notes.
Access: Authorized access and operation-specific mutation checks.

POST /api/cc/fx-presets: Save or remove named effect presets
Contract: POST { name, config } saves; { deleteId } removes. Apply a preset through the normal theme controls.
Access: Authorized member; preset validation and mutation lock check.

GET/POST /api/cc/gallery: Browse and upload managed images
Contract: GET lists. POST supports upload, finalize and delete operations; upload receipts are completed through the media service.
Access: Main administrative access is guarded. Sennett trial has a separate, restricted upload/ownership path.

POST /api/cc/log-ip: Record an administrative network visit
Contract: POST resolves request and member context for access/visit records.
Access: Administrative logging route; its request context determines the recorded identity.

POST /api/cc/mutate: Mutate supported business collections
Contract: POST { entity, op, payload }; entities: tasks, changelog, approvals, monthly, notes, assets. Operations: create, update, delete, notes.
Access: Member and allowlist check plus Emergency Lock. Its checks are separate from the console and passkey endpoints.

GET/POST /api/cc/security: Inspect and maintain security policy
Contract: GET reads allowed settings; POST selects the implemented save, IP-check or access-verification operation.
Access: Action-specific member, administrator, and verification rules. Do not treat every operation as an equivalent access contract.

GET /api/cc/source: Browse the source bundled with this build
Contract: GET lists files; GET ?path=<known path> returns text for that exact bundled path.
Access: Authorized member. Read-only; unavailable paths return 404. No live filesystem access.

POST /api/cc/theme: Update website or workspace appearance
Contract: POST selects a supported theme, palette, font, icon, background, effect, size, or surface operation. Separate selectors choose website and workspace targets.
Access: Administrative permission and target restrictions; Sennett trial follows its own narrower rules. Validate one intended operation per request.

POST /api/cc/users: Provision an ordinary platform account
Contract: POST { email, name }; response includes the created/reused account and provisioning information.
Access: Explicit administrator, origin check, configured passkey check, Emergency Lock, and ten-account capacity enforcement.

POST /api/cc/webauthn: Register, authenticate and manage passkeys
Contract: POST actions: register-options, register-verify, auth-options, auth-verify, list, rename, revoke.
Access: Member identity, action-specific ownership/admin rules, server challenges and credential verification.

POST /api/cms/logo-upload: Change the draft logo
Contract: POST handles toggle, revertImage, upload and finalize. Upload goes through managed media; toggles select supported visibility flags.
Access: CMS authorization and lock guard. Writes draft scope.

POST /api/cms/publish: Publish the draft to a named page
Contract: POST { slug }; copies content, structure, style and logo, then records the destination.
Access: CMS authorization and lock guard. Slug validation and all four snapshot writes must succeed before the registry update.

POST /api/cms/revert-all: Reset editable draft copy
Contract: POST resets all editable text overrides.
Access: CMS authorization and lock guard. This is a text reset, not a structure or publication rollback.

POST /api/cms/revert: Reset one draft text field
Contract: POST { id } restores the selected field’s original copy.
Access: CMS authorization and lock guard; field ID must resolve.

POST /api/cms/save: Save draft text and scale
Contract: POST { id, text, scale }; validates the registered field and its bounds.
Access: CMS authorization and lock guard; writes draft content.

POST /api/cms/structure: Edit draft components
Contract: POST action add, duplicate, delete, reorder or updateField; groupId plus the relevant itemId, fieldKey, value, direction and optional steps.
Access: CMS authorization and lock guard; validates group, item, field type and structural bounds.

POST /api/cms/style-save: Save the draft design
Contract: POST selects one supported style operation, such as { surface: "website", theme: "win11" }.
Access: CMS authorization and lock guard. Uses the supported draft-style subset, not every resolved Themes property.

POST /api/forms/submit: Accept a public business inquiry
Contract: POST submits the contact form fields; validation, a honeypot and per-instance throttling precede the stored submission.
Access: Public lead capture intentionally remains available during an administrative Emergency Lock.

POST /api/track: Record website activity
Contract: Tracking route records supported page and visitor context for first-party reporting.
Access: Public collection path; server code determines accepted context. This does not expose private visitor records.

FEATURES, MECHANISMS AND BENEFITS
WORKSPACE & EVERYDAY TOOLS
PC NET DESK: A desktop workspace for website operations, reporting, and everyday work.
How: The browser desktop launches management apps in movable, resizable windows with a shared launcher, taskbar, and notifications.
Why: Keeps the information and controls for related work visible together.

App launcher & window controls: Find apps and manage what is on screen.
How: Grouped app shortcuts open windows; controls move, resize, minimize, maximize, close, and snap them. The browser remembers supported window layouts.
Why: Lets the operator choose between a focused full-size app and several visible tools.

Desk & Core Console Settings: Manage the operator’s workspace preferences.
How: Dedicated settings control the desktop and dashboard separately from the public website. Export, import, and reset tools manage supported workspace records.
Why: Makes the workspace comfortable to use while keeping visitor-facing design decisions separate.

Notifications: Review supported workspace and access updates.
How: The notification tray combines access activity, new leads, detected AI crawler activity, and change-log updates. Selecting an event opens its related app, and a local seen-state distinguishes new activity.
Why: Makes changes discoverable while the operator works in other tools.

Photo Gallery & Camera: Capture, upload, and reuse images.
How: The gallery accepts uploaded media and browser-authorized camera captures, then makes supported images available to the platform’s editing and appearance tools.
Why: Keeps reusable imagery close to the pages and designs that need it.

Asset Library: Organize logos, images, icons, and documents.
How: The library groups reusable files and references by type for discovery and selection.
Why: Gives brand material a consistent home and reduces repeated uploads.

Web Browser: Open a website from a contained workspace view.
How: An embedded browser view loads destinations that allow embedding, with an external-tab route where available.
Why: Keeps reference material close to the work while respecting the destination’s own access and framing rules.

Installable website, Console & Desk: Launch the three experiences as separate installed web apps.
How: Separate web manifests provide stable app identities, icons, start URLs, and standalone presentation for the public website, Core Console, and PC NET DESK. Installation support depends on the browser.
Why: Makes a frequently used workspace easier to find and open from the device.
Detail: Installation describes the app shell; it does not promise an offline copy of live administrative data.

Saved window layouts & preferences: Return to a familiar arrangement of work.
How: Browser-local storage remembers window positions, sizes, minimized and maximized states, appearance preferences, and notification read state. Layout persistence is separate from shared business records.
Why: Reduces repeated setup while keeping each operator’s device comfortable to use.

Mobile workspace behavior: Use the same apps on a smaller screen.
How: Desk presents apps at full screen on mobile and disables desktop drag, resize, and snapping behavior at that size. Website background and appearance controls also distinguish desktop from mobile.
Why: Preserves usable controls and reading space across devices.

ANALYTICS, SEARCH & MARKETING
Owner Summary: See website performance and operational priorities together.
How: Connected reporting supplies headline traffic, inquiry, marketing, and health indicators; detailed modules explain the activity behind the summary.
Why: Provides a useful starting point for deciding what deserves attention.

Lead Tracking: Track inquiries, their sources, and their progress.
How: Connected inquiry records bring source, date, contact context, and stage into a reviewable lead view.
Why: Shows which channels generate inquiries and what needs follow-up.

Conversion Funnel: Follow the journey from arrival to inquiry.
How: Connected stage totals compare visits, service-page interest, contact-page activity, and recorded calls or form submissions over the selected period.
Why: Reveals where people progress and where the path needs improvement.

First-party Analytics: Review recorded website visits and visitor context.
How: The site records page paths, timestamps, referrers, and browser context. The reporting layer groups related visits and enriches network records with available location and organization information.
Why: Makes the site’s own activity available beside the tools used to improve it.

AI Analytics: Track detected AI crawlers and visits referred by AI services.
How: Recorded agent activity is classified separately from human referrals; recognizable referrers and campaign information identify supported AI traffic sources.
Why: Shows how machine discovery and AI-driven referrals contribute to site activity.
Detail: A crawler visit shows access; it does not establish that an AI answer recommended the business.

Google Analytics 4: Review acquisition, engagement, page activity, and events.
How: Connected GA4 reports supply users, sessions, engagement measures, sources, devices, landing pages, and instrumented events.
Why: Connects acquisition quality with what visitors actually do after arriving.

Search Console: Track search queries, visibility, clicks, and page performance.
How: Connected search reporting compares impressions, clicks, click-through rate, position, queries, and pages across reporting periods.
Why: Identifies pages to improve and the search demand they could serve.
Detail: Search queries describe aggregate search performance; they are not a transcript of each individual visitor’s searches.

Service Pages: Compare attention and response across services.
How: Page-level reporting associates service paths with visits, engagement, and recorded inquiry actions.
Why: Helps prioritize services and page improvements using observed interest.

Geographic: See where website attention comes from.
How: Connected reports group activity by available country, region, and city estimates, with source and page context where available.
Why: Supports service-area planning and content suited to the markets attracting attention.

SEO Opportunities: Turn search performance into a list of improvements.
How: Search indicators and page comparisons highlight opportunities such as improving titles, answering questions, and deepening useful service content.
Why: Connects visibility gaps with concrete work for the content and website tools.

Meta / Facebook Ads: Review paid campaign delivery and response.
How: Connected campaign reports show spend, reach, impressions, clicks, leads, and cost per lead for the reporting period.
Why: Makes paid traffic accountable to the website activity and inquiries it produces.

Social Organic: Track the reach and response of organic social content.
How: Connected social reporting brings follower trends, reach, engagement, and post performance into the same review environment.
Why: Helps connect publishing effort with the topics and channels that attract interest.

Call Tracking: Include telephone inquiries in acquisition reporting.
How: The call-provider connection supplies recorded call activity and attribution for comparison with website and campaign reporting.
Why: Makes phone response visible alongside forms and other digital inquiries.
Detail: A phone-link click and a provider-recorded call are different events.

Website Health: Review the website’s operational condition.
How: Connected checks report availability, links, forms, tracking, indexing, sitemap, certificate, and page-speed findings.
Why: Brings technical problems into the same workflow as content and marketing improvements.

Competitor Snapshot: Compare competitors’ visibility, services, reviews, and website presentation.
How: Connected competitor research organizes public information and third-party estimates into a consistent comparison, with a source and reporting period for interpretation.
Why: Helps prioritize credible differentiation and useful content improvements.
Detail: Competitor traffic estimates are distinct from your own first-party analytics; this does not expose competitors’ private visitor records.

VISITOR INTELLIGENCE
Visitor profiles: Understand who is visiting at the level the available evidence supports.
How: Visit records group network and browser context, first and latest activity, and the paths seen. Identified inquiry records provide contact context when someone supplies it.
Why: Distinguishes anonymous interest from an actual known inquiry.
Detail: A network or organization match is not a verified personal identity; shared networks and changing devices affect grouping.

Company, location & device: See the setting behind a visit.
How: Network enrichment supplies available organization and approximate geography; browser context supplies device, operating system, and browser.
Why: Helps assess service-area fit and the experience visitors receive on different devices.

Traffic sources & campaigns: Track where visitors came from.
How: Referrers and UTM campaign parameters feed source and medium reporting across search, paid campaigns, social, referrals, direct, and recognized AI sources.
Why: Shows which channels bring useful attention rather than just volume.
Detail: Direct or unknown traffic is retained when the source cannot be established.

Page paths & journeys: See the pages a visitor viewed and their order.
How: Timestamped page records and connected session reports reveal entrances, subsequent pages, repeated views, and exits within the observed visit.
Why: Shows the routes people take through services, proof, FAQs, and contact information.

Time & engagement: Measure how long visits and page interactions last.
How: Connected session and event reporting supplies duration and measured engagement time at the available session and page level.
Why: Helps separate a brief arrival from a visit involving deeper interaction.
Detail: Elapsed time and active engagement measure different things; neither proves that every word was read.

Clicks, events & conversions: Track the interactions that move a visitor forward.
How: Instrumented events record supported link and button clicks, phone and email actions, downloads, outbound links, and form activity with page and event context.
Why: Reveals which calls to action work and where interest stops short of an inquiry.
Detail: A click, a successful submission, and a completed call remain distinct outcomes.

Return visits & continued interest: Recognize repeat activity in the available reporting window.
How: First-party grouping and analytics identifiers expose repeat activity where the browser and collection context allow it.
Why: Helps identify topics attracting continued attention and compare new with returning engagement.
Detail: Cross-device visits or cleared identifiers do not automatically resolve to one person.

Intent analysis: Interpret why a visitor may have come.
How: Source, landing page, page sequence, time, and actions provide evidence for an operator’s intent assessment, such as researching a service or seeking support.
Why: Turns activity into a useful hypothesis about what the website should explain next.
Detail: Intent is inferred from behavior; the visitor’s stated purpose is stronger evidence.

COMPETITOR INTELLIGENCE
Search & content gaps: Compare discoverability and useful topic coverage.
How: Connected search research and public-page reviews compare queries, ranking pages, and content coverage for a consistent market and period.
Why: Finds questions and topics that deserve a better answer on your own site.

Services & positioning: Review how alternatives describe their offer.
How: Compare public service pages, locations, audiences, offers, evidence, and calls to action in a structured competitor view.
Why: Helps make your own service proposition clearer and more distinctive.

Reviews & website experience: Assess trust signals and the experience competitors present.
How: Public ratings, review themes, navigation, mobile presentation, and a consistent website-review rubric support like-for-like comparisons.
Why: Turns competitive research into specific improvements to clarity, credibility, and usability.

Research to action: Connect a competitive gap to a website improvement.
How: Record the finding, create the follow-up task, develop a Builder page or content change, and review your own connected results after publication.
Why: Makes competitive analysis useful to delivery instead of leaving it as a disconnected report.
Detail: Public observations and third-party estimates do not reveal a competitor’s private traffic, customers, or conversion performance.

WORK & REPORTING
Forms: Review inquiries and record follow-up.
How: Submission records support status changes and private notes, with matching commands for supported actions.
Why: Keeps an inquiry’s current state and next action together.

Tasks / To-do: Create, complete, and remove work items.
How: Editable task records are read from the configured collection; the command registry also supports adding, completing, reopening, and removing them.
Why: Makes the next action explicit and allows supported visual and textual workflows to use the same records.

Approval Center: Record a review decision.
How: The pending queue supports approve and reject actions on its records; matching authenticated commands call the same status update functions.
Why: Keeps decisions attached to a defined item instead of relying only on an informal conversation.
Detail: An approval record does not by itself mean that website publishing is automatically gated by that approval.

Calendar: Plan dated work and milestones.
How: Event records place deadlines and scheduled work inside the same workspace as the tools used to deliver them.
Why: Keeps upcoming work visible while making changes and reviewing results.

Clock & heartbeat: Inspect time and automation-runner activity.
How: The clock shows working time; recorded heartbeat timing helps explain when the scheduled-action runner last checked for due work.
Why: Gives the operator context for schedule execution and troubleshooting.

Monthly Reports: Review performance across reporting periods.
How: Connected monthly-report records preserve period summaries for comparison with the underlying traffic, marketing, and operational information.
Why: Builds a review history that makes changes and priorities easier to discuss.

Strategy / Client Notes: Keep decision context and priorities available.
How: The notes editor reads and saves persistent written context within the platform.
Why: Preserves the reasoning behind a decision alongside the metrics and tasks.

Change Log: Review recorded changes and releases.
How: Dated entries carry a version, change type, and description for operational review.
Why: Helps relate a website change to subsequent behavior or performance.

WEBSITE & DESIGN
Website Style Engine: Control the look of the selected website.
How: A per-website style record drives theme, scheme, icon, font, background, sizing, and effect settings.
Why: Coordinates many components from a shared set of decisions and preserves the selected website’s scope.

Website Background: Choose separate images for desktop and mobile.
How: Background controls draw from built-in and uploaded images. The style system supports per-page overrides and a return to the site default.
Why: Allows the composition to fit the screen and the page rather than forcing one image everywhere.

Welcome Message: Update the website’s introductory message.
How: A focused editor changes the designated welcome or hero message for its assigned website.
Why: Makes a frequent content adjustment quick to find and perform.

Website Builder: Edit a structured draft and publish a named page.
How: The Builder saves content, repeaters, section order, design, and logo state. Publication creates or replaces the selected page’s independent snapshot.
Why: Supports dedicated pages while keeping work in progress separate from published content.

Color Scheme Builder: Create and reuse coordinated palettes.
How: The source supports named custom schemes with brand and neutral color values, including separate light/dark and website/console settings.
Why: Avoids repeating a collection of individual color choices every time a treatment is reused.

Core Console Style: Tune the dashboard’s own appearance.
How: Console-specific theme and presentation settings operate separately from website style settings.
Why: Lets the operator optimize the working interface without changing the public-facing brand experience.

Desk Style & Desk Background: Customize the desktop shell.
How: Dedicated controls manage the desktop theme, accent, icons, type, backgrounds, and supported effects.
Why: Keeps desktop personalization independent from the site and the dashboard.

Six visual families: Change the character of the website or workspace.
How: Default, Windows 11, iOS, Android, Ubuntu, and Soft UI each provide a coordinated CSS treatment. Website, Core Console, and Desk can have independent selections.
Why: Provides a coherent starting point instead of styling every component separately.

Independent typography & icon families: Fine-tune identity within a chosen theme.
How: Five font families and six icon families can be selected independently. Fonts use the registered web or system font stacks; the icon renderer maps the same semantic icon to its selected family.
Why: Retains consistent meaning while changing the visual voice.

Light, dark & custom neutral colors: Keep both color modes intentional.
How: Eight built-in palettes and custom schemes define five brand color roles. Custom neutral sets control background, surface, panel, border, muted copy, and text for website and Console light/dark contexts.
Why: Keeps brand accents, surfaces, and reading contrast coordinated.

Ten animated background effects: Give a page a controlled sense of motion.
How: Network, Rain, Circuit, Hex, Packets, Warp, Aurora, Radar, Grid, and Signal share adjustable intensity, amount, density, speed, strength, and two colors; Off disables the effect.
Why: Makes a distinctive presentation reusable without editing animation code.

Pointer, click & touch responses: Control how an effect reacts to the visitor.
How: Attract, Spawn, Repel, and Trail can be combined. Separate settings govern pointer parameters, click or tap responses, double-click boosts, and whether the effect runs on mobile.
Why: Lets the operator balance interaction, motion, and the needs of different devices.

Reusable effect presets: Save a motion treatment and use it again.
How: Named presets store a validated effect configuration. Apply a preset to the selected website, Console, or Desk surface; delete presets that are no longer needed.
Why: Reduces repeated tuning and makes a preferred treatment reproducible.

Mobile reading glass & scroll blur: Adjust the background as the reader moves through a page.
How: At widths up to 980 pixels, two independent scroll-driven effects use an ease-out ramp. Controls set activation, ramp distance, maximum opacity, and maximum blur for the reading overlay and background blur.
Why: Keeps the opening view expressive while making longer reading more comfortable.

Component size controls: Adjust the density of supported page elements.
How: Six size settings scale service, product, and Why Us cards, chips, badges, and FAQ items from 60% to 180%. CSS variables coordinate padding, icon size, and radius within each element type.
Why: Changes visual emphasis while retaining the component’s proportions.

Per-page background inheritance: Give a registered page its own background.
How: The Contact page currently supports desktop and mobile image overrides. Removing an override restores the selected website background. Developers can register more pages in the same system.
Why: Creates page-specific identity with a clear fallback to the site-wide design.

Console panels, header & menu surfaces: Tune the structure around the work.
How: Default, flat, glass, and gradient treatments expose a color and opacity for Console panels, header, and menu surfaces. Desk has its own appearance settings and starts from Console defaults until overridden.
Why: Makes the operator’s workspace legible and personal without changing the public website.

WEBSITE BUILDER ENGINE
Field selection & text fitting: Edit the website’s registered content in context.
How: Click supported preview text or search the field list, then edit within the field’s length and fit constraints. Shared rendering applies the site’s text-fitting behavior.
Why: Makes content easier to find and reduces layout problems caused by oversized copy.

Repeaters & nested content: Build out cards, lists, navigation, products, and FAQs.
How: Supported collections expose add, duplicate, delete, and reorder controls; nested product bullets and collection size limits preserve the component structure.
Why: Expands a page without rebuilding every repeated item by hand.

Section order: Arrange the body of the page around its purpose.
How: Move supported middle sections while Hero remains first and Contact remains last.
Why: Allows a different narrative while preserving a predictable entrance and response point.

Design & logo controls: Give the draft a complete visual identity.
How: The Builder’s Style tab controls logo upload and visibility, theme, palette, font, icons, backgrounds, sizing, and effects.
Why: Keeps content and visual refinement in one editing context.

Draft scope & rendered preview: Review a page before exposing the next version.
How: The draft keeps content, structure, style, and logo state together and renders the site’s components in preview scope.
Why: Shows how the actual website system treats the work before publication.

Named pages & snapshots: Publish a dedicated page at a chosen destination.
How: Choose a valid page name or an existing target. Publication copies the draft into independent records at /published/name; replacing a target asks for confirmation.
Why: Supports service, campaign, location, and audience pages with deliberate replacement and separate published state.

A registered content model: Edit a known part of the page with predictable rules.
How: The base schema defines 124 text fields in ten sections. Each field has a stable ID, visual role, label, original copy, line and character limits, and allowed text scale. Added repeater items receive their own field identities.
Why: Gives people and agents precise targets and keeps text fitting tied to its actual component.

Bounded components & directional movement: Rearrange supported groups without losing their structure.
How: Ten groups define the allowed item types and minimum/maximum counts. Grid-based groups support row-aware movement, product cards contain one to eight nested bullets, and six middle sections can be reordered between the fixed Hero and Contact sections.
Why: Allows meaningful composition while protecting the layout’s basic shape.

Text restoration with a defined scope: Return copy to its original wording.
How: Restore one registered text field or reset all editable text. Original copy lives in the schema; item deletion and order belong to the separate structure model.
Why: Makes a copy reset understandable and avoids treating it as a whole-site rollback.

Content boundaries & shared structured data: Keep editable copy consistent with the page’s behavior.
How: The Builder edits registered copy and components. Business contact channels, metadata, form labels, and animated stat numbers have separate implementation controls. Product wordmarks are editable through their repeater fields. FAQ output uses the same resolved content for visible answers and structured data.
Why: Protects functional details and reduces disagreement between visible content and machine-readable answers.

WEBSITE AUTOMATIONS
Scheduled setting changes: Prepare changes to 32 supported website settings.
How: Each action selects a registered theme, palette, background, readability, motion, or interaction setting. Typed validation checks its value before storage.
Why: Makes automated changes explicit and predictable.

One-time, daily & weekly schedules: Choose when a website setting should take effect.
How: The action stores its scheduled date and time and an optional daily or weekly repeat rule; recurring actions advance to their next due time after running.
Why: Supports planned launches and recurring presentation routines.

Action management: Control the schedule as plans change.
How: Name, edit, enable, disable, or delete an action; inspect its next scheduled time and last-run information.
Why: Makes upcoming work visible and lets an operator pause or revise it.

Execution & heartbeat: Apply due changes and leave an execution record.
How: The runner checks enabled actions during website or Console renders, throttled to once per minute per running instance. A 15-minute heartbeat covers quiet periods, applies due values, refreshes settings, and records last-run time.
Why: Balances reliable checks with a lightweight system that does not need a continuously running scheduler.
Detail: These actions target the main website’s registered settings. Builder publishing is a separate action; this scheduler changes registered website settings.

ADMINISTRATION & AUTOMATION
Users: Review authorized users and provision ordinary platform accounts.
How: The administrator supplies a name and email. The system reserves a seat, creates or reuses a Wix member, approves and authorizes it, and requests a set-password email. The reviewed implementation caps authorized accounts at ten; a new account does not become an administrator.
Why: Gives access a deliberate owner, a visible capacity limit, and a repeatable onboarding path.
Detail: Email acceptance is recorded separately from delivery. A failed provisioning attempt does not grant access.

Recent Access: Review administrative access history.
How: Access records expose timestamps and outcomes for inspection.
Why: Supports investigation and accountability with a usable event history.

Security & Emergency Lock: Control access to administrative tools.
How: Member checks, allowlists, configured passkey enforcement, IP policy, alerts, and Emergency Lock support the platform’s administrative access rules.
Why: Restricts sensitive operations and gives the administrator controls for responding to access concerns.

Automations: Schedule supported website settings to change.
How: A saved action contains a setting, validated value, scheduled time, repeat rule, and enabled state. The due-action runner applies the change and records execution.
Why: Handles planned and recurring presentation changes without a manual visit at every scheduled time.

Console command interpreter: Use defined commands for supported operations.
How: A fixed registry validates commands and dispatches to the same functions used by supported authenticated tools. It is not an operating-system shell.
Why: Provides a direct route for repeated tasks without adding arbitrary code execution.

Files: Browse the implementation from the workspace.
How: The Files app lists build-bundled source files and opens their text through an authorized, read-only endpoint. It does not browse the live server filesystem or edit deployed code.
Why: Lets maintainers and authorized agents understand the implementation behind an interface without leaving the workspace.

Build Notes: Keep architecture and operating knowledge accessible.
How: An in-platform documentation view provides implementation, setup, and operating notes.
Why: Preserves the knowledge needed to maintain and extend the system.

Passkey registration & device management: Use a device-backed credential for protected access.
How: WebAuthn registration and verification pair browser credentials with server challenges and stored public-key records. Authorized controls list, rename, and revoke passkeys; the administrator can enable enforcement.
Why: Supports strong sign-in without asking an agent or operator to handle a reusable password for every action.

IP access policy: Manage the network addresses allowed by the configured policy.
How: The security view exposes validated IP entries and an enable switch. Server and administrative access flows apply their implemented identity and policy checks.
Why: Gives the administrator an additional control for the intended operating environment.

Denied-access alerts: Make rejected access attempts visible.
How: Supported access flows record denied attempts, expose unacknowledged alerts, and use configured notification settings. The administrator can acknowledge reviewed alerts.
Why: Turns access concerns into reviewable activity instead of relying on someone noticing an error screen.

Emergency Lock & recovery: Pause protected changes during an incident.
How: Emergency Lock is checked by protected mutations and the scheduled-action runner. Its explicit recovery flow can lift the lock; the public lead form remains available.
Why: Creates a way to interrupt administrative changes while continuing to accept business inquiries.

DEMONSTRATION & PRESENTATION
Demo Mode: Walk through the platform’s feature surface.
How: The demonstration interface guides the viewer through selected panels and explanatory steps.
Why: Introduces the system without requiring the viewer to know its navigation first.

Presentation Mode: Present the workspace as an organized story.
How: A presentation surface provides a sequential walkthrough with navigation and supported voice options.
Why: Connects features to their purpose during a demonstration.

Voice Mode: Read supported interface summaries aloud.
How: Browser speech synthesis uses device voices and user-controlled playback.
Why: Offers an optional spoken route through the platform explanation.

About PC NET DESK & Core Console: Understand the platform’s purpose and feature surface.
How: The About app introduces the workspace, its capabilities, and its operating model.
Why: Helps a new operator understand the system before exploring individual tools.

AI READINESS & AGENT WORKFLOWS
Created for people and agents: Give software agents understandable ways to operate the platform.
How: The design pairs visual tools with registered text commands, structured records, explicit scopes, and inspectable source. Agents can work through an authorized browser session and supported command routes.
Why: Lets an agent translate a task into named operations and explain the result in the same terms as a human operator.

Discoverable command vocabulary: Find the supported operations before acting.
How: The help command lists 27 command families; help followed by a command explains its syntax. Double quotes keep multi-word arguments together.
Why: Reduces guesswork and makes repeatable tasks easier to plan.

A JSON command contract: Submit a defined operation and read its result.
How: An authenticated POST to /api/cc/console accepts a command string and returns output lines plus an isError flag. Commands are limited to 500 characters; the technology reference documents the exact response behavior.
Why: Provides a small, explicit integration surface that an authorized agent adapter can use.

Shared visual and command behavior: Reach the same underlying operation in two ways.
How: Registered commands call the functions used by the supported visual modules. Operations such as task status, notes, approvals, forms, and due-action execution reuse the platform’s data layer.
Why: Reduces the chance that clicking a control and issuing a command produce different business behavior.

Typed targets & explicit scopes: Tell an agent exactly what can change.
How: Stable field IDs, component group IDs, value registries, record IDs, and live/draft/published scopes describe the target of a change. The Builder keeps content, structure, style, and logo state separate.
Why: Supports precise edits, easier review, and a clear explanation of the affected state.

Authorized agent operation: Carry the operator’s access rules into automated work.
How: Agent use of administrative surfaces requires the appropriate member identity, permissions, and applicable passkey or lock checks. A browser session or separately implemented adapter supplies that context.
Why: Keeps automation tied to an accountable identity and the operation’s actual access rules.

Read, act & verify: Check the outcome before reporting completion.
How: Read the current record, issue one scoped operation, inspect HTTP and command error information, then read the affected record or page again. A timed-out write needs a state check before a retry.
Why: Helps an agent avoid duplicate work and distinguish a successful request from the intended result.

Machine-readable reference: Let an agent consume the same feature and technical model as a reader.
How: This guide provides a JSON catalog and a plain-text agent reference containing capability explanations, command syntax, schemas, API descriptions, and operating constraints. The files are read-only documentation.
Why: Makes discovery and handoff easier without requiring an agent to infer contracts from screenshots.

AI discovery & traffic visibility: Understand how AI systems encounter the website.
How: Public content and structured FAQ data make the site readable; llms.txt offers a discovery summary. AI Analytics separates recognized crawler activity from supported AI referral traffic.
Why: Connects machine discovery with observable visits while keeping agent operation and traffic measurement distinct.

EXTENSION POINTS
A new management app: Add a cc component, register the dashboard/Desk entry, connect a shared service and protected endpoint where needed. Keep visual rendering and business operations separate so another interface can reuse the same operation.

A new agent command: Add a COMMANDS entry with usage, summary, handler, mutation/admin classification and the necessary lock checks. Expose a narrow operation, return an explicit error result, and verify the resulting state. Mixed command families need subcommand review.

A new content field: Register its ID, section, role, original copy and fit bounds; render it with the CMS-aware text component. Keep original content, visible copy, preview behavior and machine discovery in agreement.

A new repeater or section: Define its template, stable field mapping, limits and renderer. Extend structure operations for any new field type. Ensure duplicate, delete and reordering preserve valid identities and component boundaries.

A new theme or style control: Add the theme/style definition, server validator, UI control, persisted value and rendering rule for the intended surface. Updating a dropdown alone does not make a new theme or setting functional.

A new scheduled setting: Extend FIELD_DEFS, value validation and the website settings writer, then expose the control in Actions. Use a value that the live renderer already understands; do not silently treat publication as a style setting.

A new reporting source: Connect a server-side provider adapter, map its metrics, preserve period/source attribution and supply the module data. Keep measured events, enriched estimates and inferred intent distinguishable.

An agent adapter / MCP tool: Implement a separately authenticated integration that maps approved tools to the existing narrow operations. The reviewed repository supplies commands and HTTP routes; it does not bundle an LLM, MCP server, API-key agent SDK or autonomous planner.

The JSON catalog contains the full field, repeater, style, schedule and source inventories. The documentation site remains static and does not connect to private application data.