Capablio enterprise uplift — Cursor dual-wiki prompt pack

What is in this pack

This is an implementation prompt hierarchy, not a visual mockup or a completed application. It contains:

• A screen-by-screen audit of the supplied 18-screen prototype.
• A target product and information architecture.
• A dual-wiki operating model so customer-facing truth and internal system truth remain synchronized.
• Layout, design-system, accessibility, responsive, and data-visualization rules.
• Role and data-visibility models for global administrators, tenant administrators, HR, managers, users, and external raters.
• Copy-paste Cursor prompts sequenced from repository discovery through release hardening.
• Starter AGENTS.md, flat .cursor/rules/*.mdc files, wiki manifests, templates, and traceability scaffolding.

Source material used

• 20260717T081249Z.zip: 18 current-state Capablio screenshots and short page descriptions.
• capablio-framework-v0.1.zip: adaptive question, cadence, cooldown, PDP, rotation, tenant-overlay, analytics, privacy, integration, and pricing architecture.
• 360 Report Leonid Zvyahintsev(2).pdf: Thomas-compatible input shape and report concepts.
• Leo_360_Snapshot(2).pdf: development-conversation, anonymity, interpretation, and PDP concepts.

The product name is normalized to Capablio, matching the supplied application screens. Do not silently rename domains, packages, legal entities, or existing database identifiers without an explicit migration decision.

Recommended use

1. Copy starter/AGENTS.md, starter/.cursor/rules/, and starter/wiki/ into the repository root.
2. Run prompts in numeric order. Do not run implementation prompts in parallel unless they touch disjoint applications and share a frozen design-system version.
3. Start with Cursor Ask or Plan mode for prompts 00 through 02; they are discovery and architecture prompts.
4. Allow code changes beginning with prompt 03 only after the dual wiki, route map, role matrix, and architecture decisions exist.
5. At the end of every prompt, require Cursor to update both wikis, the feature index, and the traceability matrix.
6. Keep one commit or pull request per prompt unless a prompt explicitly defines smaller feature slices.

Prompt hierarchy

Read first

• 00-current-state-audit.md
• 02-dual-wiki-operating-model.md
• 04-layout-and-design-system-guidelines.md
• 05-role-permission-and-data-visibility-model.md
• 07-prompt-hierarchy.md

Important boundaries

• Capablio is a development and feedback product, not a diagnostic, compensation, disciplinary, or automated employment-decision engine.
• Imported Thomas data is external evidence. It must retain source lineage and must not be blended into native longitudinal trends without an explicit, validated bridge.
• Never expose raw JSON, internal IDs, bearer tokens, encryption-envelope terminology, or database states in normal user interfaces.
• Global platform operators must not gain plaintext access to tenant feedback merely because they can administer the platform.
• A role label is not sufficient authorization. Every server-side operation must evaluate tenant, resource, action, scope, and data class.
• Do not fabricate customer logos, testimonials, certifications, benchmark claims, usage numbers, or security attestations on the marketing site.