OpenYida CLI

The agent-center skill allows you to query, create, edit, and revoke proxy settings for active employees (in-service) and departing employees (resignation). This is used to set up proxy persons for process approvals or submissions.

Critical Safety Requirements

• Confirm Identities: Before any operation, you must confirm the userId and department path of both the source user (the person being proxied) and the target user (the proxy person) using agent-center search-user. Never rely on names alone.
• Verify Existing Proxies: Use agent-center list --keyword <userId> to check if proxy records already exist before creating new ones.
• Permission Constraints: Resignation proxies (--type departure) can only be managed by platform administrators. If you receive a permission error, do not retry; instead, prompt the user to switch to an administrator account.
• Time Range Requirements:
  • For normal (in-service) proxies, you must provide both --start and --end timestamps.
  • For resignation proxies, do not provide time parameters; the proxy becomes effective based on the user's resignation status.
• Partial Range Requirements: If using --range part, you must specify the scope via --range-form <appType:formUuid>, --range-json, or --range-file.

The soft-spectral-panels theme is characterized by a near-black canvas with slightly lighter, large-rounded theme-dark panels. It uses a high-contrast approach where brand-colored solid interactive elements are paired with dark foreground text, while data focus is achieved through localized highlights (fine lines, light nodes, and small glows).

Core Design Principles

• Low-saturation layered surfaces: Uses a near-black shell and slightly lighter content cards with soft, rounded boundaries. Avoid filling backgrounds with high-saturation brand colors.
• Large rounded surfaces with compact controls: Outer cards have significant corner radii, while inputs and controls use smaller radii. Avoid using a single corner radius for all objects.
• Brand interactions and sparse data colors: Primary interactions use brand backgrounds with dark foregrounds. Specific colors like 'Acid Yellow' and 'Dark Red' are reserved for real data series, not for success/error states.
• Localized highlights for readings: Use light points, thin vertical lines, and small reading bubbles to emphasize specific positions. Avoid large-scale neon effects or continuous animations that disrupt attention.

OpenYida uses a strict verification protocol to determine if a platform operation is a PASS. A successful API response (e.g., success) is insufficient on its own. To achieve a PASS, the following criteria must be met:

1. Applicable Local Contract: The operation must satisfy the local contract/schema requirements.
2. Platform Publish/Exact Readback: The platform must successfully publish the change, and a subsequent 'exact readback' (reading the data back from the server) must match the intended state.
3. Runtime Side-effects/Provenance/Restore: For runtime-sensitive operations, there must be evidence of unique side-effects, provenance (origin tracking), or successful restoration of state.
4. UI Evidence: Screenshots or UI states serve only as supplementary evidence and cannot replace API/Platform readback.

Common verification statuses include:

• PLATFORM_PUBLISH_PREVIEW_RUNTIME_VERIFIED: Control plane and runtime preview are verified.
• PLATFORM_READBACK_VERIFIED: Data was successfully written and read back exactly.
• PLATFORM_CONTROL_PLANE_VERIFIED_RUNTIME_PROBE_REQUIRED: The configuration (control plane) is correct, but the actual runtime behavior requires further probing.

The platform provides a base set of semantic variables (for navigation, forms, tables, etc.) that must be preserved. To implement a unique project style, you should extend these variables rather than replacing them.

Extension Strategies

• Project Extensions: Add variables for gradients, textures, font hierarchies, content widths, grid spacing, materials, shadows, animations, and component states.
• Naming Conventions: Use project or component-specific namespaces. While --oyd-* is the existing convention, you may use specific prefixes like --magazine-* to avoid masquerading as platform-supported variables.
• Consumption: Clearly document which component or CSS property a new variable serves. New variables can be shared across multiple custom pages and components.
• Value Types: Match CSS property requirements (e.g., use color values for background-color platform variables, but use gradients/images for theme variables consumed by background-image).

When implementing custom navigation, understand how the URL and routing interact:

• Purpose vs. Display: The path (workbench vs submission) determines the intent (management vs entry), while parameters (hideLeftNav vs isRenderNav) determine the visual display (navigation visibility). They are independent.
• Updating Content: When using a custom navigation shell, you should update the content within the iframe for same-app navigation.
• Cross-Page Navigation: For transitions between different real pages, use the data bridge: router.push(href, params, false, true).
• URL Integrity: Always use full URL patterns when calling router.push to prevent the router from incorrectly prepending application prefixes or failing to resolve the path. The data bridge supports omitting the fourth parameter to auto-identify full addresses, but explicitly passing false is supported.

// Use the data bridge for cross-page navigation
// router.push(href, params, [isReplace], [isFullUrl])
router.push(fullUrl, params, false, true);

When publishing changes to OpenYida, you can choose between two strategies. Understanding the trade-offs is critical for maintaining system stability, especially when using AI agents.

Full Replacement

Model: New Schema = f(Local Code)

• Pros: Deterministic, reproducible (can test offline), and independent of the current online state. It is highly predictable for AI models.
• Cons: It ignores the current online state and will overwrite any manual changes made by users directly on the production environment.

Partial Merging

Model: New Schema = f(Local Code, Current Online State)

• Pros: Protects user data by preserving manual online configurations.
• Cons: Introduces a 'live, untrusted input' (the online state). This makes the process non-deterministic, harder to reproduce locally, and more complex for AI agents to reason about.

Key takeaway: Partial merging is safer for data but riskier for system predictability. If using merging, you must implement engineering safeguards (backups, validation, and honest summaries) to compensate for the loss of determinism.