Build boldly. Publish safely.

Know what Studio owns

Portal Studio owns the customer-facing shell: pages, component placement, brand tokens, responsive behavior, navigation, footer, identity presentation, ticket journeys and releases. The Help Center owns languages, categories, sections and article content. Studio consumes that content through a protected bridge; it never creates a second article store.

Complete readiness before building deeply

1. Abrir Portal Studio → Start → Readiness.
2. Confirm the canonical Portal address and open it in a separate tab.
3. Set the logo, browser icon, touch icon, social image and theme color.
4. Confirm Help Center languages; change language authority in Help Center, not Studio.
5. Configure navigation and the global enterprise footer.
6. Choose a ticket journey and configure at least one request form.
7. Keep at least one safe sign-in method active and review identity discovery.
8. Run Quality and establish the signed preview handshake.
9. Create the first governed release after every blocking item is clear.

The readiness percentage is calculated from saved workspace data and preview state. Selecting an item routes directly to its owning panel.

Build pages and reusable sections

1. Abrir Build → Pages and select a protected system page or create a custom page.
2. Set the route, title, access mode and locale behavior. Protected system routes cannot be deleted.
3. Abrir Components, filter by job or maturity, and place a component in a compatible slot.
4. Use the inspector for content, appearance, binding, visibility and accessibility.
5. Use reusable patterns for repeated structures; keep organization or brand differences in variants.
6. Save the draft and exercise loading, empty, error, guest and signed-in states in preview.

Design one navigation and footer for every route

1. Abrir Build → Navigation & footer.
2. Create ordered desktop links and nested or mega-menu groups; confirm keyboard and mobile behavior.
3. Configure the enterprise footer: brand, grouped links, contact, social, trust, newsletter, legal links, locale and status.
4. Use audience and locale conditions only where necessary; URLs, routes and IDs are never translated.
5. Preview public, customer and organization personas at mobile, tablet and desktop widths.

Preview real journeys, not one happy screen

1. Choose guest support, signed-in ticket, billing care, organization or knowledge handoff.
2. Switch personas, organization, role and Help Center language.
3. Inspect mobile, large mobile, tablet, laptop, desktop, wide and ultrawide breakpoints.
4. Check inherited, overridden and reset values; avoid needless breakpoint duplication.
5. Run keyboard, RTL, reduced-motion, loading, empty, unavailable and permission states.
6. Use Test Lab for accessibility, payload, route, binding and renderer findings before review.

Operate a Zendesk-level Help Center without duplicate content

1. Create categories, sections, articles, translations, attachments and templates in Help Center.
2. Enable languages there; localized slugs, search, feeds, SEO and article chrome follow the same authority.
3. In Studio, place knowledge search, category/resource grids, feeds, topic accordion, article, table of contents, feedback, related and previous/next components.
4. Configure featured, popular and recent feeds; use contextual suggestions in ticket flows.
5. Preview no-results, long articles, attachments, feedback, watch/subscription and ticket handoff.
6. Verify clean locale routes, canonical/hreflang, structured data and cache invalidation after publication.

Configure sign-in safely

1. Abrir Identity & organizations → Identity and keep at least one sign-in path enabled.
2. Choose default method, registration policy, session duration, SSO-domain enforcement and discovery behavior.
3. Add providers with visual routing fields: type, domains, priority, presentation, enabled and verified state. Secrets stay in the identity subsystem.
4. For SCIM, enable provisioning, copy the exact workspace endpoint and rotate the token. Store the one-time token in the IdP.
5. Map claims and organization membership, then test create, update, group membership and deactivation with a test tenant.
6. Preview guest, customer, delegated organization and blocked states before publication.

Compose the complete support journey

1. Select direct form, wizard, search-first, hub or service-desk entry.
2. Create a named, versioned request form with sections and accessible field labels.
3. Build visual conditions, routing, SLA and approval steps; advanced JSON is for reviewed developer changes only.
4. Configure list, detail, thread, timeline, attachment, approval, SLA and reply surfaces.
5. Test guest lookup, signed-in requests, organization visibility, upload failure, email notification and knowledge deflection.
6. Save a draft; publish only after the route adapter and notification path pass preflight.

Move through a governed release

1. Run validation and Test Lab. Fix blocking findings; acknowledge permitted warnings with context.
2. Add release notes and request review. Reviewers comment on stable page/node paths.
3. Approvers inspect the diff, preview journeys, permission changes and evidence.
4. Publish or schedule through the background worker. Leaving Studio does not cancel a durable job.
5. Watch progress, health and correlation ID. Stop/retry only from job controls.
6. Verify critical routes, identity, tickets and knowledge. Roll back to an immutable prior release when required.

Migrate with evidence and a way back

1. Select the provider blueprint and create a dry run.
2. Review discovered settings, unmapped values, content counts and visual parity captures.
3. Complete safe mappings and rerun the structured diff.
4. Apply to a draft, reconcile counts and preview every protected journey.
5. Record authorized acceptance; never overwrite the current published release during import.
6. Publish through governance and keep the migration report, release ID and rollback point together.

Extend contracts, not templates

A safe extension registers a stable component type and schema, declares permissions and data needs, renders through the canonical compiler, and supplies deterministic fixtures/tests. Do not query arbitrary tables, inject editor JavaScript into the public Portal, create another article repository, or bypass the release gate.

Define a component package

Use a lowercase namespaced ID and semantic version. Supply both compatibility property names shown because package inspection and security validation perform independent checks.

{
  "schema_version": 1,
  "id": "acme.support_health",
  "slug": "acme-support-health",
  "name": "Support health",
  "version": "1.0.0",
  "entry": "renderer.php",
  "renderer": "server",
  "server_renderer": "renderer.php",
  "public_renderer": "public.js",
  "schema": {
    "type": "object",
    "properties": {
      "heading": {"type": "string", "maxLength": 120},
      "showSla": {"type": "boolean", "default": true}
    },
    "additionalProperties": false
  },
  "permissions": ["tickets.read"],
  "data_scopes": ["tickets.mine"],
  "accessibility": {
    "landmark": "section",
    "nameFrom": "heading",
    "emptyState": true,
    "errorState": true
  },
  "performance": {"max_js_bytes": 12000, "max_css_bytes": 8000},
  "performance_budget": {"js": 12000, "css": 8000, "requests": 0}
}

Node shape

{
  "id": "node-support-health",
  "type": "custom.acme_support_health",
  "props": {"heading": "Support health", "showSla": true},
  "bindings": {"requests": {"source": "tickets.mine", "limit": 5}},
  "responsive": {"mobile": {"padding": "16px"}, "desktop": {"padding": "24px"}},
  "conditions": [{"field": "identity.signed_in", "operator": "equals", "value": true}],
  "a11y": {"label": "Support health"}
}

• IDs remain stable across edits and migrations.
• Properties reject undeclared fields and unsafe HTML.
• Every data-bound view defines loading, empty, permission and retryable-error output.
• Container components name their slots; leaves cannot accept arbitrary children.
• Mark maturity honestly: planned blocks, beta warns, GA requires full evidence.

Use permission-safe DTOs

1. Choose an existing dotted ID such as tickets.mine, knowledge.featured o customer.profile.
2. Bind only fields declared by its versioned DTO. Unknown sources fail with data_source.unknown.
3. Pass the already-authorized Portal context; never accept workspace/customer identity from an untrusted property.
4. List limits are clamped to 1–100. Normalize pagination, locale and search values.
5. If a new source is unavoidable, add its stable definition, safe mapping, permissions, empty behavior and preview fixture together.

{
  "success": true,
  "source": "tickets.mine",
  "contract_version": 1,
  "items": [
    {"id": 42, "number": "REQ-42", "subject": "Example", "status": "open"}
  ]
}

Stay inside the trust boundaries

{
  "success": false,
  "error": {
    "code": "studio.permission_denied",
    "message": "You do not have permission to publish the Portal.",
    "retryable": false,
    "correlation_id": "ps_…",
    "meta": {"capability": "publish"}
  }
}

Inspect, install and upgrade atomically

1. Put component.json at the ZIP root and keep every path relative.
2. Run inspection first. The installer caps archives at 500 entries and 25 MB extracted; security validation adds independent limits.
3. Verify the expected SHA-256 and package signature in the release process.
4. Install to a versioned directory. Never mutate an installed version in place.
5. Provide property migrations for breaking schema changes and preserve unknown compatibility fields.
6. Open the component in a draft, run every state/viewport/persona fixture and publish through governance.
7. Rollback activates the prior immutable component/document release; retain its reproducibility evidence.

Prove the extension on the same release hash

php tools/portal_studio_certify.php --source-only --json
php tools/test_portal_studio_v2.php
php tools/test_portal_studio_ultimate.php
php tools/test_portal_studio_engineer.php
php tools/test_portal_component_contracts.php
php tools/test_portal_one_renderer.php
php tools/test_portal_shell_contract.php
php tools/test_portal_knowledge_contract.php
node tools/test_portal_studio_ultimate_browser.js

Source gates are necessary, not sufficient. Attach database/migration, real-browser visual, identity-provider, authorization-isolation, accessibility, performance, queue/cron, mail/attachment, backup/restore and deployment evidence to the same immutable release hash. Unknown required evidence must fail the release.

• Unit: schema, sanitization, DTO shape, conditions, migrations and typed failures.
• Contract: loading/empty/error/success, maturity, slots, bindings and one-renderer parity.
• Browser: keyboard, focus, semantics, RTL, zoom/reflow, reduced motion and every breakpoint.
• Security: cross-workspace probes, forged actions, package attacks, preview spoofing and secret leakage.
• Operations: durable progress, leave/return, stop/retry/resume, scheduler heartbeat and rollback.

Troubleshoot by state and correlation ID