organization

Every section below is settled — this organization has already decided it. Anything not below is open: interview for it normally.

• In an interview (start, interview, refine): answer from the settled section and move on, recording it as a line carrying the source tag [org default] (prd-contract). The user can override it in chat like any other decision, and the override wins.
• At design time: a settled section pins its provider or technology outright. A settled capability gets no suggestions list — it is a given, not a choice left to the user.

Authentication & identity

Every web app signs its users in via SSO through Thunder, the platform IDP. Thunder is available as a dependency.

Security & compliance

security-design owns how a permission catalog is derived and what specs/design/security.json may say. This section is a pointer, not a specification: it holds only the calls that skill deliberately leaves to the organization, because they are about the org's own shared directory rather than about one project. A filled line is settled and is never asked at design time; an empty one leaves the call to security-design.

The call	This organization's answer
May a design introduce a new org group?	Yes, but only where list_groups shows no existing group is already those people.
Groups to prefer, by name.	(none — the directory is the list)
Groups a role may never be assigned to.	Administrators. It administers the platform, not any generated app.
Is self-service enrolment permitted?	Only where the PRD describes people who sign themselves up.

Changing how a design derives groups, roles and scopes starts here: this is the org-editable surface, and security-design is platform-owned and read-only in the console. A change it cannot express is a change to that skill.

Technology stack

• Web apps: TypeScript + React, single-page app.
• Services and APIs: Ballerina.

UI design system

oxygen-ui-design-system

That is the name of a skill in this library, and it is the single authority for this organization's web-app UI — components, layout, styling, theming, and the verification step a web-app build owes it. This section is a pointer, not a specification: what the design system requires is stated in that skill and is never restated here, so the two can never disagree.

To adopt a different design system, change the name above and make sure a skill by that name exists. Those are the only edits — nothing else in the library names a design system. Leave this section empty to run with no design system at all; web-app builds then carry only the stack skills.