Հարթակի կառավարում

Պարզ ասած՝ սա ամբողջ հարթակի կառավարման սենյակն է, ոչ թե որևէ մեկ կազմակերպության — ստորև վեց էջերը (Organizations, Users, Products, Platform Roles, Staff, Audit Log) թույլ են տալիս P4P-ի սեփական թիմին կառավարել հարթակն օգտագործող յուրաքանչյուր ընկերություն, ոչ միայն իրենը։ Սա առանձին տարածք է «Workspace» էջերից, որոնք տեսնում է կազմակերպության սովորական անդամը։

Ամեն ինչ /platform/*-ի տակ։ Հասանելի է /dashboard-ի Platform Administration մուտքի կետից, բայց, ինչպես այս մոդուլի ցանկացած էջ, պահանջում է platform:admin:access (middleware/platform-admin-access.ts), ոչ միայն SUPER_ADMIN-ը։ Մինչև 2026-08-14 միակ դարպասն այստեղ ցանկացածPlatformRole ունենալն էր ընդհանրապես — սա նշանակում էր, որ հարթակի աշխատակիցը, ում իրական աշխատանքը Աշխատակազմ էր (platform:staffing:*, /team/*), դեռ կարող էր բացել այս ողջ կառավարման սենյակը։ Յուրաքանչյուր առանձին route-ն արդեն փակված էր իր իրավունքով, այնպես որ ոչինչ իրականում խոցելի չէր — բայց այդ մարդը պատճառ չուներ ընդհանրապես բացելու այս բաժինը։ platform:admin:access-ը հիմա այդ հիմնական մուտքի դարպասն է, պարտադիր ԼՐԱՑՈՒՑԻՉ ձևով յուրաքանչյուր բաժնի սեփական իրավունքին (read/manage-ի հետևողական բաժանում ողջ մոդուլում — դիտումը առանց :manage իրավունքի թույլատրված է. փոփոխող գործողությունը թաքցված է կամ արգելափակված)։ Ամբողջ նկարագրության համար, ներառյալ admin-users.controller.ts-ի մի քանի route-ները, որոնք միտումնավոր թողնված են այս դարպասից դուրս, քանի որ /team/members-ը (Աշխատակազմ) ուղղակիորեն կանչում է դրանք («Send on leave»/ «Return from leave») — տես 2026-08-14-ի գրառումը docs/iam/PERMISSIONS_CATALOG.md-ում։

Բոլոր կոնտրոլերները այստեղ գտնվում են @UseGuards(PlatformRoleGuard)-ի հետևում կոնտրոլերի մակարդակում (ինքնաբավ, առանց TenantGuard-ի հերթականությունից կախվածության — ի տարբերություն կազմակերպության մակարդակի PermissionsGuard-ի, տես IAM)։ SUPER_ADMIN-ը անվերապահորեն շրջանցում է PlatformRoleGuard-ը։

Ինչպես անել...

Խմբավորված է նույն կերպ, ինչ տեխնիկական բաժինները ստորև — յուրաքանչյուր էջի օգնության պատկերակը տանում է հենց իր խումբը, ոչ թե այս ամբողջ ցանկը։

Վահանակ

Հասնել բաժնին — /platform/dashboard, այն էջը, որը բացվում է Հարթակի կառավարում կոճակով. յուրաքանչյուր բաժնի համար քարտ (Աշխատանքային տիրույթներ, Օգտատերեր, P4P անձնակազմ, Պրոդուկտներ, Դերեր), յուրաքանչյուրն իր կենդանի հաշվիչներով։ Ցուցադրվում են միայն այն բաժինները, որոնք իրականում կարող ես կարդալ — նեղ հարթակային դեր ունեցող ադմինիստրատորը տեսնում է կարճ հանգույց, ոչ թե խամրած քարտեր։

Տեսնել, թե ինչ են հենց նոր արել այլ ադմինիստրատորները — քարտերի տակ Վերջին ակտիվությունը վահանակը՝ աուդիտի հինգ թարմ գրառում, յուրաքանչյուրի մոտ հեղինակը և որքան ժամանակ է անցել, գումարած կարմիր Սխալ նշումը այն ամենի մոտ, ինչ չհաջողվեց։ Տողի վրայով անցիր՝ կտեսնես այն ամբողջությամբ և սխալի պատճառը։ Դիտել բոլորը-ը բացում է լիարժեք Աուդիտի մատյանը։ Վահանակին պետք է platform:audit:read իրավունքը, առանց դրա այն ընդհանրապես չկա։

Կարդալ «—» հաշվիչը — այդ թիվը չի բեռնվել, կամ քո հարթակային դերը չի կարող կարդալ այդ բաժինը. …-ը նշանակում է, որ այն դեռ բեռնվում է։ Յուրաքանչյուր սալիկ ձախողվում է առանձին՝ առանց հանգույցը գցելու։

Կազմակերպություններ

Ստեղծել կազմակերպություն հարթակի կողմից — «Organizations» → Նոր աշխատանքային տիրույթ → Անուն/տիրույթի URL/Տեսակ → Ստեղծել։ Տես դաշտերի ուղեցույցը։

Վերցնել կառավարումը կանգնած կազմակերպության — բացիր կազմակերպությունը → Դառնալ սեփականատեր → նշիր Պատճառը → Շարունակել → հաստատման համար մուտքագրիր տիրույթի անունը։ Միայն SUPER_ADMIN։ Տես դաշտերի ուղեցույցը։

Վերասահմանել կազմակերպության լռելյայն լեզուն — բացիր կազմակերպությունը → Լռելյայն լեզու → ընտրիր ցանկից։ Միայն SUPER_ADMIN — վերասահմանում է նույն կարգավորումը, որը կազմակերպության OWNER-ը կառավարում է իր տիրույթի ներսից (տես IAM → Կազմակերպության կարգավորումներ), առանց անդամ լինելու պահանջի։

Տալ կամ հետ վերցնել կազմակերպության հասանելիությունը մի արտադրանքի — բացիր կազմակերպությունը → դրա Products բաժինը → Ակտիվացնել/Ապաակտիվացնել տվյալ արտադրանքը։ (Ինքը «Products» էջը խմբագրում է միայն կատալոգը՝ անուն/նկարագրություն/ակտիվություն, ոչ թե ով ինչին է բաժանորդագրված)։

Ստեղծել կազմակերպություն — դաշտերի ուղեցույց

• Անուն (պարտադիր) — 2–100 նիշ։
• Տիրույթի URL (պարտադիր) — 2–50 նիշ, միայն փոքրատառ լատինատառեր, թվեր և գծիկներ։ Ինքնաբերաբար լրացվում է Անունից, մուտքագրման ընթացքում (օրինակ՝ «Acme Corp» → acme-corp) — սկսիր ինքդ խմբագրել այն, և այս ինքնալրացումը մշտապես կանգնում է այս երկխոսության մնացած ընթացքի համար, նույնիսկ եթե հետո նորից փոխես Անունը։ Պետք է լինի եզակի ամբողջ հարթակում; զբաղված արժեքը բռնվում է միայն ուղարկելիս, ոչ մուտքագրման ընթացքում։
• Տեսակ — Company / Individual / Agency / Service provider / Platform / Personal։ Միայն Personal կազմակերպություններն են ստեղծվում արդեն Active; ցանկացած այլ տեսակ սկսվում է Pending-ով (կարգավիճակների նշանակությունները տես կազմակերպության սեփական մանրամասների էջում)։

Դառնալ սեփականատեր — դաշտերի ուղեցույց

Այս կոճակը երևում է միայն նրա կողքին, ով հենց հիմա ունի OWNER դերը, և միայն այն SUPER_ADMIN-ի համար, ով ինքը այդ սեփականատերը չէ։ Այն թույլ չի տալիս սեփականությունը հանձնել ընտրված անդամին — դրա վրա կտտոցը միշտ դարձնում է նոր սեփականատեր հենց քեզ, սեղմող ադմինիստրատորին (անհրաժեշտության դեպքում նախ միացնելով քեզ կազմակերպությանը, եթե արդեն անդամ չես); նախկին սեփականատերն իջեցվում է սովորական MEMBER-ի, ոչ հեռացվում։

• Պատճառ (1-ին քայլ, ոչ պարտադիր) — ազատ տեքստ, զուտ գրառում նրա համար, ով հետո կարդում է աուդիտի մատյանը։
• Հաստատման տեքստ (2-րդ քայլ, պարտադիր) — պետք է մուտքագրես կազմակերպության ճշգրիտ Անունը, նախքան վերջնական Դառնալ սեփականատեր կոճակն այլևս ապաակտիվ չլինի։

Օգտատերեր

Ջնջել օգտատիրոջ հաշիվը — «Users» → տողը → Ջնջել → հաստատել։

Հեռացնել ինչ-որ մեկին հարթակի անձնակազմից — բացիր օգտատիրոջը → Հեռացնել թիմից։ Փակում է նրա անձնակազմի անդամակցությունը և բոլոր հարթակային դերերը, բայց չի ջնջում հենց հաշիվը։

Տալ ինչ-որ մեկին հարթակային դեր կամ դարձնել հարթակի նոր սեփականատեր — բացիր օգտատիրոջը → Հարթակի դերեր → նշիր դերերը → Պահպանել դերերը։ Հենց սեփականության փոխանցումն առանձին կոճակ է նույն էջում՝ Փոխանցել սեփականությունը այս մարդուն։

Ուղարկել աշխատակցին արձակուրդ կամ վերադարձնել այնտեղից — այս գործողությունը այստեղ ընդհանրապես չկա; դա «⋯» մենյուն է նրա պրոֆիլի վրա Աշխատակազմ → Աշխատակիցներ-ում։

Հրավերներ հարթակի անձնակազմ

Հրավիրել ինչ-որ մեկին P4P-ի ներքին թիմ — «Staff» → Հրավիրել հարթակի անձնակազմ → Email, ցանկության դեպքում նախապես նշիր Հարթակի դերեր → Ուղարկել հրավեր։ Տես դաշտերի ուղեցույցը։

Հրավիրել հարթակի անձնակազմ — դաշտերի ուղեցույց

Սա խմբաքանակային հրավեր է. տողերի դինամիկ ցանկ, յուրաքանչյուրն իր սեփական Email + Հարթակի դերեր զույգով, +/–-ով տողեր ավելացնելու և հեռացնելու համար։

• Email (պարտադիր, յուրաքանչյուր տողում) — ձևաչափի ստուգում չկա, բացի «ոչ դատարկ»-ից; սխալ հասցեն, կամ արդեն անձնակազմում/հրավիրված հասցեն, բռնվում է միայն ուղարկելիս — և միայն այդ տողն է ձախողվում, ոչ ամբողջ խմբաքանակը։
• Հարթակի դերեր (ոչ պարտադիր, յուրաքանչյուր տողում) — բոլորը դատարկ թողնելը լիովին նորմալ է. հրավիրվածը պարզապես կսկսի առանց որևէ հարթակային դերի, ինչը նորմալ վիճակ է, ոչ թե բաց — Team Management-ի հասանելիությունը գալիս է հենց հարթակի անձնակազմում լինելու փաստից, անկախ կոնկրետ դերից։ Այս դաշտը զուտ դերեր նախապես նշանակելու միջոց է։ Սերմային Owner/SUPER_ADMIN դերերը երբեք չեն երևում այս ցանկում — դրանք հրավերով հնարավոր չէ տալ, միայն «Դառնալ սեփականատեր»-ի կամ օգտատիրոջ էջից ուղղակի դերի փոխանցման միջոցով։
• Ուղարկել հրավեր-ը ուղարկում է ամբողջ խմբաքանակը մեկ հարցումով։ Ուղարկումն ապաակտիվանում է, քանի դեռ որևէ տող ունի վավերացման կամ սերվերի մերժման սխալ, և վերաակտիվանում է հենց այդ կոնկրետ տողը խմբագրելուն պես; ձախողված տողը ցույց է տալիս իր սեփական պատճառը՝ ներտողային, ոչ մեկ թոստ ամբողջ խմբաքանակի համար։

Ապրանքներ և բաժանորդագրություններ

Խմբագրել, ինչպես է արտադրանքը երևում կատալոգում — «Products» → տողի ⋯ → Խմբագրել → Անուն/Նկարագրություն → Պահպանել փոփոխությունները։ Արտադրանքի ամբողջ հարթակով միացում/անջատումը առանձին գործողություն է նույն մենյուից; կոնկրետ կազմակերպության հասանելիության տրամադրումը/հետ վերցնելը արվում է հենց այդ կազմակերպության էջից — տես Կազմակերպություններ վերևում։ Տես դաշտերի ուղեցույցը։

Խմբագրել արտադրանք — դաշտերի ուղեցույց

• Անուն — պարտադիր, 2–100 նիշ։
• Նկարագրություն — ոչ պարտադիր, մինչև 2000 նիշ։
• Այստեղ ուրիշ ոչինչ չի խմբագրվում — այս երկխոսությունը միայն այն է փոխում, թե ինչպես է արտադրանքը նկարագրված կատալոգում։
• Ակտիվացնել/ապաակտիվացնել (ամբողջ հարթակով) այս երկխոսության մաս չէ — դա տողի սեփական անջատիչ գործողությունն է, հետադարձելի, առանց հաստատման։ Արտադրանքն անջատելը միանգամից թաքցնում է այն բոլոր կազմակերպությունների համար, անկախ նրանց յուրաքանչյուրի բաժանորդագրության կարգավիճակից։

Դերեր

Ստեղծել սեփական հարթակային դեր — «Roles» → Ստեղծել դեր → անվանիր, ընտրիր իրավունքներ → պահպանիր։ Տես դաշտերի ուղեցույցը։

Խմբագրել, կրկնօրինակել կամ ջնջել դերը — դերի ⋯ → Խմբագրել, Կրկնօրինակել կամ Ջնջել։ Խմբագրել-ը և Ջնջել-ը չեն առաջարկվում ներկառուցված համակարգային դերի համար, քանի որ այն հնարավոր չէ ո՛չ վերանվանել, ո՛չ հեռացնել — Կրկնօրինակել-ը և Դիտել իրավունքները դեռ աշխատում են։ Օգտատիրոջը դեր նշանակելը/հեռացնելը կատարվում է հենց օգտատիրոջ էջից — տես Օգտատերեր վերևում։ Կրկնօրինակել-ը նախապես լրացնում է նույն ձևը գոյություն ունեցող դերի իրավունքներով (ներառյալ համակարգայինի), անվանելով «Կրկնօրինակ ⟨օրիգինալ⟩» — ոչինչ չի պահպանվում, մինչև իրապես ուղարկես ձևը։

Ստեղծել/խմբագրել հարթակային դեր — դաշտերի ուղեցույց

Առանձին էջ է, ոչ պատուհան, որպեսզի իրավունքների ցանկը ունենա շնչելու տեղ։ Ներկառուցված համակարգային դերերը (օրինակ՝ SUPER_ADMIN) երևում են նույն ցանկում, բայց ընդհանրապես Խմբագրել գործողություն չունեն և երբեք չեն կարող ջնջվել; Կրկնօրինակել-ը և Դիտել իրավունքները-ը դեռ աշխատում են դրանց վրա։

• Անուն — պարտադիր, մինչև 100 նիշ, նվազագույնը 2։ Պետք է լինի եզակի բոլոր հարթակային դերերի մեջ։
• Նկարագրություն — ոչ պարտադիր, մինչև 2000 նիշ։
• Իրավունքներ — օգտագործիր որոնման դաշտը կամ բացիր մեկ բաժինը մեկ առ մեկ (Organizations, Users, Roles, Աշխատակազմ և այլն)։ Ոչ մի նշված իրավունք չունեցող դերը վավեր է — այն պարզապես ոչինչ չի տալիս։ Չեքբոքս ամեն բաժնի սեփական վերնագրի վրա մեկ սեղմումով ընտրում կամ հանում է այդ բաժնի բոլոր իրավունքները; երկրորդ չեքբոքսը որոնման դաշտից վերևում նույնն անում է միանգամից բոլոր բաժինների համար, հաշվի առնելով ակտիվ ֆիլտրը — այնպես որ ֆիլտրված տեսքի վրա «ընտրել բոլորը»-ն ազդում է միայն այն բանի վրա, ինչ ներկայումս ցուցադրվում է։
• Կապված P4P Internal դեր (ոչ պարտադիր) — ընտրություն, սահմանափակված P4P Internal-ի սեփական դերերով (Team Manager/Team Admin/Team Member և այլն); տես վերևում, թե դա իրականում ինչ է անում նշանակման ժամանակ։
• Պահպանել/Ստեղծել-ը ակտիվանում է միայն երբ բեռնվածից իրապես ինչ-որ բան փոխվել է։

Աուդիտի մատյան

Կարգավորելու բան չկա — դա միայն դիտման համար է։ Ֆիլտրիր ըստ գործող անձի/գործողության/ժամանակահատվածի հենց էջում; տես Աուդիտի մատյան ստորև, թե կոնկրետ ինչ է գրանցվում և ինչու է դա առանձին սովորական ադմինիստրատիվ աշխատանքից։

Հայտարարություններ

Գրեք կարճ Վերնագիր և Հաղորդագրություն, ապա՝ Ուղարկել։ Իրական ուղարկումից առաջ կա հաստատման երկխոսություն — սա հասնում է յուրաքանչյուր P4P աշխատակցի ծանուցումների զանգին և փոստին միանգամից, և հետ կանչել հնարավոր չէ։ Առանձին պատմության էկրան չկա այստեղ — թե ով ինչ է ուղարկել և երբ, գրանցվում է Աուդիտի մատյանում ստորև (platform.announcement.sent), ինչպես ցանկացած այլ հարթակի ադմինիստրատիվ գործողություն։

AI օգնականներ

Բացել հարթակային օգնականներին — Կարգավորումներ → AI օգնականներ։ Յուրաքանչյուր գլոբալ օգնականի համար քարտ. այսօր մեկն է՝ Platform Assistant։

Փոխել այն, ինչ ասված է նրան — բացիր → Վարքագիծ → Հրահանգներ → Պահպանել փոփոխությունները։ Այնտեղ մի՛ թվարկիր նրա գործիքները. հարթակն արդեն մոդելին տալիս է ճշգրիտ ցանկն այն բանի, ինչից կարող է օգտվել՝ որոշելով դա յուրաքանչյուր մարդու համար ըստ իր իրավունքների, և ձեռքով պահվող պատճենը հնանում է հենց նոր գործիք ավելացնելու պահին։ Հենց դա էլ եղավ մինչև 10.09.2026-ը։

Փոխել մոդելը — բացիր → Մոդել։ Առաջարկվում են միայն հարթակի կատալոգում միացված մոդելները, քանի որ անջատվածի վրա ձախողվում է ամեն պատասխան։ Սա այստեղի ամենաարժեքավոր կարգավորումն է. թույլ է տալիս կանխադրված օգնականին տեղափոխել ավելի էժան կամ ավելի նոր մոդել՝ առանց դեպլոյի։

Վերանվանել — բացիր → Անվանում և նկարագրություն։ Ո՛չ անվանումը, ո՛չ նկարագրությունը մոդելին չեն ուղարկվում. դրանք մարդկանց են պետք նրան ճանաչելու համար։

Տեսնել, ով է փոխել — ցանկի ներքևի հղումը կամ աուդիտի մատյանը՝ AI օգնականներ ֆիլտրով (ai_assistant.updated)։ Այստեղի ամեն փոփոխություն միանգամից ընկնում է բոլոր տարածքների վրա — դրա համար էլ գրանցվում է։

Ինչը չի կարելի փոխել և ինչու

Էջի երեք բլոկ նշված են Կառավարվում է հարթակի կողմից և դաշտեր չունեն։ Դրանք թաքցված չեն, որովհետև նա, ով գիտի սովորական գործակալի էջը, կգա դրանք փնտրելու.

• Գործիքներ — հարթակի ներկառուցված գործիքները միշտ միացված են և պատասխանում են հարցնողի իրավունքներով, տալու բան չկա։ Արտաքին MCP կապակցումը պատկանում է մեկ տարածքի, ուստի ընդհանուր օգնականի վրա տրված թույլտվությունը մնացած բոլորին ոչինչ չէր տա։
• Հղումային նկարներ — ամրակցված նկարը վերցվում է հարցնողի անունից, իր տարածքի ներսում. այստեղ վերբեռնվածը ոչ մի այլ կազմակերպության մոտ չի բացվի։
• Ավտոմատացում և ժամանակացույցեր — ժամանակացույցը պատկանում է մեկ կազմակերպության, իսկ ընդհանուր օգնականն այդպիսին չունի։ Առանց մարդու աշխատանքը թույլատրելը կնշանակեր, որ ցանկացած տարածք կարող է նրան ֆոնում գործարկել իր անունից։

Գեներացիայի պարամետրերը (temperature, top-p, պատասխանի առավելագույն token-ներ — Որոշում 20) այս էջում էլ չեն ցուցադրվում, ի տարբերություն սովորական տիրույթային գործակալի, որի մոտ դրանք կան Կարգավորում → Մոդել բաժնում։ Հենց այդ նույն երեք սյունակներն ունի ցանկացած գործակալի պես — այս էջի ձևը դրանք պարզապես դեռ չի առաջարկում։

AI մոդելներ

Բացել կատալոգը — Կարգավորումներ → AI մոդելներ։ Մեկ տող յուրաքանչյուր մոդելի համար, որը կարող են ընտրել բոլոր տարածքները։

Ուղղել լռած մոդելը — բացեք այն → ընտրեք Իդենտիֆիկատորը OpenRouter-ի ցանկից → Պահպանել։ Մատակարարները հանում են մոդելների իդենտիֆիկատորները, և հանվածը սխալով չի ընկնում. վերադարձվում է դատարկ պատասխան, օգնականները պարզապես դադարում են պատասխանել, և ոչ մի լոգում այդ մասին ոչինչ չկա։ Ցանկը հենց OpenRouter-ինն է, ուստի վրիպակը կամ հանված իդենտիֆիկատորը ընտրել հնարավոր չէ։ Եթե պահպանվածը արդեն ցանկում չկա, այն ցուցադրվում է առաջինը՝ Չկա OpenRouter-ի ցանկում նշումով։

Ավելացնել մոդել — + կոճակը → ընտրեք Մատակարարին, ապա մոդելը։ OpenRouter-ի համար անունը, գինը և այն, թե մոդելը կարդու՞մ է պատկերներ, լրացվում են նրա ցանկից և կարող են փոփոխվել։ Գործիքներ կանչել չկարողացող մոդելը նշվում է. դրա հետ օգնականը չի կարողանա հասնել ո՛չ գրատախտակին, ո՛չ օրացույցին, ո՛չ փաստաթղթերին։ Գոյություն ունեցող մոդելի մատակարարը փոխել հնարավոր չէ. դա արդեն այլ մոդել է, ավելացրեք նորը։

Ստուգել մոդելը մատակարարի կայքում — նրա տողի փոքր սլաքի պատկերակը կամ երկխոսության Իդենտիֆիկատոր դաշտի տակի հղումը։ Բացվում է նոր ներդիրում․ OpenRouter-ի մոդելի համար՝ նրա սեփական էջը (գին, սահմանափակումներ, հանվում է արդյոք), Claude-ի, GPT-ի և Gemini-ի համար՝ մատակարարի մոդելների ցանկը, քանի որ նրանք յուրաքանչյուր մոդելի համար կայուն էջ չունեն։ Թերի գրված իդենտիֆիկատորով մոդելը հղում չունի՝ սխալի էջ տանող հղման փոխարեն։

Հանել մոդելը շրջանառությունից — բացեք այն → անջատեք Հասանելիությունը։ Այն կմնա կատալոգում և կանհետանա գործակալների ընտրացանկից։ Հեռացնել-ը ջնջում է ամբողջովին. արդեն այն ընտրած գործակալները կպահեն կարգավորումը մինչև ձեռքով փոփոխելը, և նրանց հաջորդ գործարկումը կձախողվի։

Նշել, որ մոդելն ընդունում է նկարներ — միացրեք Նկարներ-ը։ Զրույցը կհրաժարվի նկար կցել այն գործակալին, որի մոդելն այդպես նշված չէ, փոխանակ ուղարկի և ստանա մատակարարի սխալը։

Նշել, թե որ գեներացիայի պարամետրերն է մոդելն ընդունում — Գեներացիայի պարամետրեր փոխարկիչները (Temperature, Top P, Պատասխանի առավելագույն token-ներ), կանխադրված միացված են։ Անջատեք այն, ինչ մոդելը ուղղակիորեն մերժում է (սովորաբար այդպես է «մտածող» մոդելների մոտ temperature-ի հետ) — այդ դեպքում գործակալի պահված արժեքն այդ կոնկրետ պարամետրի համար պարզապես երբեք չի հասնում այս մոդելի կանչերին։ OpenRouter-ի համար դրանք լրացվում են մատակարարի սեփական ցանկից, ինչպես Նկարներ-ը, և կարող են փոփոխվել։

Փոփոխությունը գործում է հաջորդ հաղորդագրությունից — արդեն կառուցված գործակալները վերակառուցվում են, ոչ թե մնում հին մոդելի վրա։

Վահանակ (/platform/dashboard)

Պարզ բառերով. Հարթակի կառավարման նախասրահը՝ նավիգացիոն քարտեր իրական թվերով, գումարած վերջին հինգ վարչական իրադարձությունը։ Ինքը /platform-ը միայն վերահղում է այստեղ։

Միտումնավոր ոչ վերլուծական էկրան. ոչ գրաֆիկներ, ոչ միտումներ։ Թվերը կան, որպեսզի քարտն ասի՝ արժե այն բացել, թե ոչ (78 օգտատեր, 0 սպասող հրավեր), ոչ թե որպեսզի այս էջն ուսումնասիրեն։

• Յուրաքանչյուր հաշվիչ իրական է և վերցվում է զուգահեռ նույն ցուցակային էնդփոյնթներից, որոնցից օգտվում են հենց բաժինները (/admin/organizations, /admin/users, /admin/users/platform-staff, /admin/products, /admin/platform-roles, /admin/users/platform-staff-invitations), յուրաքանչյուրը՝ իր քարտի նույն իրավունքի ներքո և յուրաքանչյուրն ինքնուրույն վերածվում է —-ի։
• Վերջին ակտիվությունը դա GET /admin/audit-log?limit=5-ն է (platform:audit:read), նույն գործողությունների թարգմանության աղյուսակով, ինչ Աուդիտի մատյան էջը. անհայտ գործողության կոդը ցուցադրվում է այնպես, ինչպես կա, այլ ոչ թե վերածվում դատարկ տողի։
• Քարտերը զտվում են ըստ իրավունքների, այլ ոչ թե արգելափակվում։ Համեմատիր հենց աշխատանքային տիրույթի գլխավոր էջի հետ, որտեղ երեք քարտերն էլ ցուցադրվում են, իսկ անհասանելիները պարզապես խամրած են. կարճ ֆիքսված հավաքածուն իմաստ ունի ցույց տալ ամբողջությամբ, երկարը՝ ոչ։
• Էջին ընդհանրապես հասնելու համար պետք է platform:admin:access (middleware/platform-admin-access.ts)։

Կազմակերպություններ (/platform/organizations, /platform/organizations/[id])

Պարզ ասած՝ հարթակն օգտագործող յուրաքանչյուր ընկերություն/գործակալություն/անհատ, որոնելի և կառավարելի մեկ ցանկից։ Ներառում է վթարային «վերցնել սեփականությունը» գործողություն այն դեպքի համար, երբ կազմակերպության իրական սեփականատերը անհասանելի է։

admin-organizations.controller.ts, տեղադրված է admin/organizations-ի վրա։

• Ցանկ / մանրամասներ / անդամներ (GET) — platform:organizations:read։
• Արխիվացված կազմակերպության վերականգնում (POST :orgId/restore, փոխադրում է ARCHIVED → ACTIVE, գրանցվում է որպես org.restored) — հաստատված է (2026-08-04, որոնում apps/portal-ում). frontend մուտքի կետ չկա։ Միակ «restore» UI-ն, որը ընդհանրապես գոյություն ունի պորտալում, կապ չունեցող Shared Documents ֆունկցիա է (փափուկ ջնջված ֆայլի վերականգնում աղբարկղից, POST /organizations/{id}/files/{fileId}/restore) — չշփոթել այս երկուսը։ Քանի որ արխիվացումն էլ UI չունի, կազմակերպությունը, որը դառնում է ARCHIVED, այսօր UI ուղի չունի հետ՝ ACTIVE վերադառնալու համար — միայն API-ով երկու ուղղություններով էլ։
• Force owner transfer (POST :orgId/force-owner-transfer, «Take ownership» մանրամասների էջում) — SuperAdminGuard, ոչ թե ընդհանուր :manage իրավունքը։ Սա հստակորեն «SUPER_ADMIN վերականգնման ուղին» է (ըստ կոդի մեկնաբանության) այն դեպքի համար, երբ կազմակերպությունը կանգնած է առանց հասանելի OWNER-ի — platform:organizations:manage ունեցողը, ով SUPER_ADMIN չէ, չի կարող օգտագործել այն։
• Լռելյայն լեզվի հարկադիր սահմանում (PATCH :orgId/default-locale, ավելացվել է 2026-08-18) — նույն սխեման, ինչ force owner transfer-ը՝ SuperAdminGuard, ոչ թե :manage, և առանց անդամության ստուգման։ Վերասահմանում է կազմակերպության սեփական, միայն OWNER-ին հասանելի լռելյայն լեզվի կարգավորումը՝ կազմակերպությունից դուրս։

«New workspace» պատուհանը ցանկի էջում ստեղծում է կազմակերպություն ուղղակիորեն հարթակի կողմից (նույն POST /organizations-ը, ինչ ինքնուրույն ստեղծման դեպքում — տես IAM); նրա կոճակը փակված է :manage իրավունքով, թեև հենց էջը պահանջում է միայն :read։

Ուղղված է, 2026-08-04. այս պատուհանը նախկինում փլուզվում էր 500-ով յուրաքանչյուր ուղարկման ժամանակ — կազմակերպությունը իրականում ստեղծվում էր տվյալների բազայում (գործարքը կատարվում է HTTP պատասխանը կառուցվելուց առաջ), բայց OrganizationsService.create()-ը վերադարձնում էր Prisma-ի հում տողը՝ OrganizationDto-ի փոխարեն, և Organization.storageQuotaBytes/storageUsedBytes-ը (BigInt սյուներ, ավելացված docs/storage/ADR-001-file-storage.md-ի համար) փլուզում են JSON.stringify-ը — այնպես որ ադմինը տեսնում էր սխալ և ոչ մի կերպ չգիտեր, որ աշխատավայրը գոյություն ունի։ getById()-ը արդեն խուսափում էր սրանից՝ ձեռքով ձևավորելով վերադարձվող արժեքը. հիմա create()-ն էլ նույնն է անում։ Հայտնաբերվել է scripts/e2e/menu/platform-admin.mjs-ի միջոցով, որը իրապես գործարկում է այս պատուհանը յուրաքանչյուր անգամ։

Օգտատերեր (/platform/users, /platform/users/[id])

Պարզ ասած՝ P4P հաշիվ ունեցող յուրաքանչյուր մարդ, բոլոր կազմակերպություններում։ Այսօր ինտերֆեյսը թույլ է տալիս միայն ամբողջովին ջնջել հաշիվը — ժամանակավոր կասեցում/արգելափակում պետք է անել ուղղակի API-ի միջոցով (կոճակ դեռ չկա)։

admin-users.controller.ts, տեղադրված է admin/users-ի վրա։

• Ցանկ / platform-staff ցանկ / platform-staff-invitations ցանկ / մանրամասներ (GET) — platform:users:read։
• Օգտատիրոջ հաշվի ջնջում (DELETE :id) — platform:users:manage, միակ հաշվի կարգավիճակի գործողությունը, որը իրապես կա այս էջի UI-ում (տողի գործողություն /platform/users-ում)։
• Suspend / activate / lock / unlock (POST :id/suspend|activate|lock|unlock) — հաստատված է (2026-08-04, որոնում apps/portal-ում). frontend մուտքի կետ չկա այս չորսից ոչ մեկի համար, չնայած որ բոլոր չորսը լիովին իրականացված են և փակված իրավունքով սերվերում։ Եթե հիմա հաշիվը պետք է կասեցնել կամ ապաարգելափակել, դա ուղղակի API-կանչ է, կոճակ չկա։
• Impersonate — «Impersonate» գործողություն այս էջում գոյություն չունի։ Հաստատված է 2026-08-04-ին. Impersonation-ը ամբողջությամբ backend-ային է (POST /auth/impersonate, միայն SUPER_ADMIN) — այս էջում դրան կապակցված կոճակ չկա, թեև սա բնական տեղն է դրա համար։
• Հեռացնել platform staff-ից (DELETE :id/platform-staff) — platform:users:manage։ Փակում է մարդու PlatformStaffMembership-ը և բոլոր PlatformRole նշանակումները. տարբերվում է նրա User հաշիվն ամբողջությամբ կասեցնելուց։
• Իրավունքների ամփոփում (2026-08-14) — օգտատիրոջ մանրամասների էջի Platform roles վահանակը ցույց է տալիս ամեն նշված դերի իրավունքների միավորման կենդանի, միայն-կարդալու ամփոփում, խմբավորված ըստ տիրույթի՝ լռելյայն-փակ ակորդեոնում, վերահաշվարկվում է ակնթարթորեն, երբ նշում/հանում ես դերերը, և նախքան Պահպանել դերերը-ի սեղմումը — նախադիտում, թե ինչ կտա փոփոխությունն իրականում, ոչ թե զեկույց, թե ինչ է հենց հիմա պահպանված։ Նույն ակորդեոն բաղադրիչն է կանգնած դիտողի սեփական պահպանված իրավունքների ընթերցման հետևում /account/profile-ում; միայն տվյալների աղբյուրն ու տեքստերն են տարբեր։
• Leave / return from leave (POST :id/leave, POST :id/return-from-leave) — platform:users:manage։ Ներքին անձնակազմի կարգավիճակ (արձակուրդում/ակտիվ), ոչ թե հաշվի մակարդակի կասեցում — ազդում է Աշխատակազմ մոդուլում առաջադրանքի/նախագծի նշանակման հասանելիության վրա, ոչ թե մուտք գործելու հնարավորության։

Հրավերներ հարթակի թիմ (/platform-staff-invitations/[token])

Պարզ ասած՝ ինչպես է ինչ-որ մեկը միանում P4P-ի սեփական ներքին թիմին (ի տարբերություն հաճախորդ կազմակերպության անդամ լինելու)։ Ուղարկվում է /platform/staff-ից — առանձին հոսք ընկերության աշխատավայր ինչ-որ մեկին հրավիրելուց։

platform-staff-invitations.controller.ts։ Հրավերի ուղարկումը (POST /platform-staff-invitations) փակված է սովորական PlatformRoleGuard-ով + platform:users:invite-ով (փոխանցվել է 2026-08-13 — տես դաշտերի ուղեցույցը վերևում) — ոչ SuperAdminGuard-ով, որն օգտագործվում է impersonation-ի և force-owner-transfer-ի համար։ SUPER_ADMIN-ը և ով էլ ունենա P4P Owner հարթակային դերը միշտ ունեն այն սերմային, լռելյայն, միտումնավոր. ինչ-որ մեկին հարթակի թիմ հրավիրելը սովորական անձնակազմի աշխատանք է, որը ընկերության Owner-ը պետք է կարողանա անել ուղղակիորեն, ի տարբերություն անվտանգության վերականգնման գործողությունների, որոնք մնում են միայն SUPER_ADMIN-ի համար։ Հրավերը երբեք չի կարող կրել SUPER_ADMIN դերի տրամադրում (ստուգվում է սերվերում, նույնիսկ եթե ուղարկումն արդեն փակված է)։ Ընդունումը (GET/POST :token[/accept], հանրային) ստեղծում է PlatformStaffMembership գրառում — նախապայման ցանկացած PlatformRole ունենալու համար (տես Բառարան)։

Ընդունման էջը (apps/portal/pages/platform-staff-invitations/[token].vue) գրեթե հայելային կրկնում է /invitations/[token]-ի սեփական ձևը՝ նույն isWrongAccount պահակը, նույն «մեկ սեղմումով ընդունում, եթե արդեն մուտք ես գործել» սկզբունքը, նույն գրանցում-vs-մուտք ճյուղավորումը — բայց միտումնավոր ավելի պարզ, քանի որ սա փոքր, հազվադեպ օգտագործվող ներքին հոսք է (docs/ROADMAP.md → Internal Company Workspace)՝ առանց magic link-ի, առանց OTP-ի, առանց Google կոճակի, և — միակ կառուցվածքային տարբերությունը, որ արժե առանձնացնել, ակնհայտ չէ արագ ընթերցումից — ընդհանրապես չկա չեզոք «Accept invitation» դարպասի կոճակ։ /invitations/[token]-ը նախ ցույց է տալիս պարզ դարպասի կոճակ և միայն սեղմելուց հետո բացում մուտքի/գրանցման ձևը; այս էջն ընդհանրապես started-ref չունի, ուստի չմուտք գործած այցելուն ուղղակիորեն ընկնում է համապատասխան ձևի վրա։ Առանց գաղտնաբառի հաշիվը (միայն Google) պարզապես ստանում է հրահանգ մուտք գործել այլուր և վերադառնալ, ոչ թե կազմակերպության հրավերի էջի ներկառուցված գաղտնաբառի վերականգնումը։

Ապրանքներ և բաժանորդագրություններ (/platform/products)

Պարզ ասած՝ ապրանքների կատալոգը, որոնց կարող են բաժանորդագրվել կազմակերպությունները, և ով ինչին է բաժանորդագրված։ Հենց ապրանքներն ավելացնում են ինժեներները, ոչ թե այս էջից — այս էջը միայն խմբագրում է, թե ինչպես են գոյություն ունեցող ապրանքները երևում, և տալիս/չեղարկում է կազմակերպության հասանելիությունը դրանց։

admin-products.controller.ts, տեղադրված է admin-ի վրա (routes. products, products/:productId, organizations/:orgId/subscriptions, subscriptions/:subscriptionId)։

• Ապրանքների կատալոգի ցանկ — platform:products:read; ստեղծում/խմբագրում/ ապաակտիվացում — platform:products:manage։ Էջի խմբագրման/ակտիվացման ցանկը տեսանելի է :read-ով, բայց օգտագործելի է միայն :manage-ով։
• Կազմակերպության բաժանորդագրություններ — ցանկը պահանջում է platform:subscriptions:read, տրամադրում/չեղարկում — platform:subscriptions:manage։ Ինքնուրույն բաժանորդագրման հոսք այսօր չկա — կազմակերպությունը չի կարող ինքն իրեն բաժանորդագրել ապրանքին. դա անում է հարթակի ադմինը։

Դերեր (/platform/roles)

Պարզ ասած՝ նույն գաղափարը, ինչ կազմակերպության Roles-ը (IAM), բայց P4P-ի սեփական ներքին թիմի համար, ոչ թե հաճախորդի — առանձին դերերի և իրավունքների հավաքածու, երբեք չի միաձուլվում կազմակերպության հետ։

platform-roles.controller.ts, տեղադրված է admin/platform-roles-ի վրա։ Նույն ձևը, ինչ կազմակերպության մակարդակի Roles էջինը (IAM), բայց PlatformRole/PlatformPermission-ի համար՝ Role/Permission-ի փոխարեն — կառուցվածքով առանձին աղյուսակների զույգ, և PermissionsGuard/TenantGuard-ը (կազմակերպության մակարդակի կիրառման ուղին) երբեք չի կարդում PlatformPermission գրանտ, նույնիսկ SUPER_ADMIN-ի համար (docs/iam/PERMISSIONS_CATALOG.md)։

Տրման հարմարություն, ավելացվել է 2026-08-19 — linkedOrgRoleId։ Հարթակային դերը կարող է ընտրովի կերպով նշել P4P Internal-ի մեկ Role (օրինակ՝ «Team Manager»), որը նաև տրվում է, երբ այս դերը նշանակվում է որևէ մեկին, նույն գործողությամբ — սահմանվում է ստորև դաշտերի ուղեցույցում։ Սա չի խախտում վերևի բաժանումը. ոչինչ PermissionsGuard-ում չի կարդում հարթակային դերի իրավունքները, և ոչինչ PlatformRoleGuard-ում չի կարդում կազմակերպության դերի իրավունքները — հարթակային դերի սեփական նշանակման հոսքը (PlatformRolesService.assignToUser) պարզապես նաև ստեղծում/թարմացնում է MembershipRole տող P4P Internal-ում՝ որպես երկրորդ, անկախ գրառում։ Հետկանչելը հանում է հենց այդ գրանտը, բացառությամբ, երբ դա կթողներ անդամակցությունն առանց որևէ դերի (լուռ բաց թողնվում է, փոխանակ հարթակային դերի հետկանչը ձախողելու անկապ անդամակցության վիճակի պատճառով)։ Սահմանափակված է P4P Internal-ի սեփական դերերով — կապվելը այլ կազմակերպության դերի հետ անիմաստ կլիներ, քանի որ հարթակային personnel-ը ինքնաբերաբար գրանցվում է միայն P4P Internal-ում։

• Դերերի ցանկ + իրավունքների կատալոգի ցանկ — platform:roles:read։
• Սերմանված SUPER_ADMIN/սեփականատիրոջ համարժեք դերի փոխանցում (PATCH owner/transfer) — միտումնավոր առանց@RequirePlatformPermission decorator-ի (տես կոդի մեկնաբանությունը 49-րդ տողում). PlatformRoleGuard-ի սեփական տրամաբանությունն այս route-ի համար ապահովում է ինչ-որ բան ավելի խիստ, քան կարող է արտահայտել իրավունքների համակարգը։ Մի ենթադրիր, թե «decorator չկա» նշանակում է «պաշտպանված չէ»։
• Հատուկ platform դերի ստեղծում / խմբագրում / ջնջում, օգտատիրոջը դեր նշանակում/հանում, դերի իրավունքի ավելացում/հեռացում — բոլորը պահանջում են platform:roles:manage։ Ինչպես նկարագրված է Հարթակի կառավարում → Օգտատերեր-ի կապակցված կատալոգի նշումներում. platform:roles:manage ունեցողը դեռ կարող է ուղղակիորեն տալ SUPER_ADMIN արդեն ակտիվ platform-staff անդամին POST :roleId/users/:userId-ի միջոցով՝ առանց լրացուցիչ պաշտպանության — հայտնի, այս պահին ընդունված բաց (տես docs/iam/PERMISSIONS_CATALOG.md, «Still open»)։

Սերմանված դերեր. SUPER_ADMIN (համակարգային, ամբողջական շրջանցում), P4P Owner և P4P Super Admin (բացահայտորեն ստանում են ամբողջ իրավունքների կատալոգը, UI-ում ցուցադրելու նպատակով — տես Բառարան), P4P Admin (ընտրված ենթաբազմություն, չի ներառում platform:roles:manage)։ P4P Member-ը ջնջվել է, 2026-08-19 — նրա իրավունքների ցանկը զրոյացվել էր դեռ նույն օրը, և վերլուծելիս պարզվեց, որ ոչ մի այլ բեռ-կրող բան այն չէր տալիս (միակ տեղը, որտեղ երբևէ իրական հասանելիությունը կապված էր «ունես ցանկացած հարթակային դեր» պայմանից, արդեն մեռած, չօգտագործվող կոդ էր այդ պահին)։ Նոր platform staff հրավիրվածը՝ առանց ընտրված դերերի, այժմ պարզապես ունի զրո PlatformRole, և իրական Team Management հասանելիությունը միշտ գալիս է PlatformStaffMembership → P4P Internal առանձին համաժամացումից, ոչ թե հարթակային դերից։ Ամբողջական հիմնավորումը՝ docs/iam/PERMISSIONS_CATALOG.md-ի սեփական թվագրված գրառումում։

Audit log (/platform/audit)

Պարզ ասած՝ միայն կարդալու դիտիչ նույն հարթակային պատմության համար, որը նկարագրված է IAM → Audit log-ում։ Միտումնավոր պահվում է առանձին «P4P Admin»-ից, ամենօրյա ադմինի դերից — բոլորի ակտիվության պատմությունը կարդալը համարվում է ավելի զգայուն, քան սովորական ադմինական աշխատանքը։

admin-audit.controller.ts, տեղադրված է admin/audit-log-ի վրա, platform:audit:read։ Միայն կարդալու դիտում միայն ավելացվող AuditLog-ի վրա (գրանցվում է ամբողջ հարթակից, ոչ միայն այս մոդուլից — տես IAM → Audit log)։ Միտումնավոր բացառված է հարմարավետ P4P Admin դերից — «ով է հսկում հսկողներին» ավելի նեղ է, քան ընդհանուր ադմինական աշխատանքը, նույն տրամաբանությունը, որ platform:roles:manage-ը պահում է այդ դերից դուրս։

Հայտարարություններ (/platform/announcements)

Պարզ ասած՝ ձև, որով սուպեր-ադմինը կարող է ասել յուրաքանչյուր P4P աշխատակցի «ահա ինչն է նոր» — և՛ իրենց ծանուցումների զանգում, և՛ էլ. փոստով — առանց դրա համար դեպլոյ պահանջելու։ Ամբողջական հիմնավորումը՝ docs/iam/PERMISSIONS_CATALOG.md-ի 2026-08-24 թվագրված գրառումում։

announcements.controller.ts, տեղադրված է admin/announcements-ի վրա, platform:announcements:manage (միայն սուպեր-ադմին — միտումնավոր բացառված է հարմարավետ P4P Admin դերից, նույն «ով է հսկում հսկողներին» տրամաբանությունը, ինչ platform:roles:manage/ platform:audit:read-ինը վերևում)։ Ստացողների ցանկը կառուցվում է հենց այնպես, ինչպես Team Management-ի ցանկացած այլ հեռարձակում՝ P4P Internal-ում workspace:staffing:read ունեցող յուրաքանչյուր անդամ, ոչ թե նոր «բոլոր հարթակի օգտատերերը» մեխանիզմ — այդպիսին չկա։ Առաքվում է ծանուցումների սովորական խողովակով (docs/notifications/ADR-001-notifications.md)՝ սեփական announcements կարգավորումների խմբի ներքո, այնպես որ ստացողը, ում դա պետք չէ, կարող է անջատել խումբը, ինչպես ցանկացած այլ խումբ՝ ամեն ինչ, բացի account_security-ից, ընտրովի է։ title/body-ն ուղարկվում են բառացիորեն և՛ որպես ծանուցման տեքստ, և՛ որպես նամակի թեմա/տեքստ — ի տարբերություն ցանկացած այլ տեսակի ծանուցման, սրանք ֆիքսված նախադասության մեջ տեղադրվող արժեքներ չեն, դրանք հենց հաղորդագրությունն են։

Միտումնավոր անկապ է դեպլոյներից և package.json-ի սեփական տարբերակի համարից (որը ցուցադրվում է առանձին՝ պորտալի սայդբարի ֆուտերում) — ոչ բոլոր դեպլոյներն են արժանի հայտարարության, և «ահա ինչն է փոխվել» գրել այնպիսի բառերով, որոնք ընթերցողը իրապես ուզում է կարդալ, կարող է միայն մարդը։ package.json-ի տարբերակի բարձրացումը առանձին, ամբողջովին ձեռքով git փոփոխություն է. հայտարարություն ուղարկելը դրա համար բնական առիթ է, բայց այստեղ ոչինչ դա ավտոմատ չի անում։

AI օգնականներ (/platform/ai-assistants)

Պարզ բառերով. այն օգնականը, ում հետ խոսում է ամեն տարածք, քանի դեռ իր գործակալները չունի, և միակ տեղը, որտեղ նրան կարելի է կարգավորել։

Սա մեկ Agent գրառում է organizationId: null-ով intelligence-ի բազայում — մեկ ընդհանուր գրառում, ոչ թե պատճեն ամեն կազմակերպության համար։ Դրա համար էլ ոչ մի տարածք չի կարող այն խմբագրել (AgentsService.findOwned-ը մերժում է organizationId: null-ը՝ պատասխանելով 404) և դրա համար էլ խմբագրելու համար պետք է հարթակային իրավունք, ոչ թե կազմակերպչական ai:agents:manage։ Ամեն տարածք դեռ տեսնում է նրան միայն կարդալու համար՝ AI Studio-ի գործակալի էջում, իսկ իրավունքի տերն այնտեղից ստանում է Կարգավորել հղումն այստեղ։

platform-agents.controller.ts-ը intelligence-ում, տեղադրված platform/agents-ի վրա։ 17.09.2026-ից իրավունքները երկուսն են. ընթերցման երթուղիները պահանջում են platform:ai_assistants:read, որը P4P Admin-ն ունի, իսկ գրառման երթուղին՝ platform:ai_assistants:manage, որը մնում է Super Admin / Owner-ի մոտ։ Նույն «հասնում է բոլորին» տրամաբանությունը, ինչ հայտարարությունների դեպքում, բայց կիրառված հրահանգների, ոչ թե ամբողջ էջի նկատմամբ. նա, ով քննում է «օգնականը դադարեց պատասխանել»-ը, պետք է տեսնի, թե որ մոդելն է դրա հետևում — իսկ առաջ դա նրան արժենում էր գրառման իրավունքը։ Էջը բացվում է ընթերցման ռեժիմում և դաշտերը պասիվացնում է, ոչ թե թաքցնում։ Այն կանգնած է PlatformAccessGuard-ի հետևում, ոչ թե OrgAccessGuard-ի, որով անցնում են intelligence-ի մնացած բոլոր երթուղիները. վերջինս պահանջում է X-Organization-Id վերնագիրը և պատասխանում մեկ կազմակերպության իրավունքներով, ինչը ոչ մեկին չպատկանող գրառման համար ուղիղ սխալ է։ Guard-ը միտումնավոր կազմակերպություն չի դնում նաև հենց հարցման մեջ. գլոբալ գրառումը, որը լուռ կապվել է այն տարածքին, որը բաց էր ադմինիստրատորի մոտ, հենց այն սխալն է, որի կանխման համար այս բաժանումը գոյություն ունի։

Փոխվում են՝ անվանում, նկարագրություն, հրահանգներ, մոդել։ Ուրիշ ոչինչ — տես ինչը չի կարելի փոխել վերևում։

Փոփոխությունները գրանցվում են որպես ai_assistant.updated աուդիտի մատյանում։ Գրառումը intelligence-ից ուղարկվում է core-api ադմինիստրատորի անունից — այնպես, ինչպես գործակալի գործարկման ավարտի ծանուցումը. մատյանը պատկանում է core-api-ին, և intelligence-ը երկրորդը չի ստեղծում։ Ի տարբերություն այդ best-effort գրառումների՝ սա ձախողվում է բարձրաձայն, և փոփոխությունը հետ է գլորվում դրա հետ. եթե չհաջողվեց գրանցել, այն չի պահպանվում։ Բոլոր կազմակերպությունների օգտագործած գրառման փոփոխությունը, որի համար հետո ոչ ոք չի պատասխանում, ավելի վատ է, քան չկայացած փոփոխությունը։

Սիդն այլևս չի վերագրանցում այն։ intelligence-ի կոնտեյները բազայի սիդը գործարկում է ամեն մեկնարկի ժամանակ, և մինչև 10.09.2026-ը սիդն ամեն անգամ վերագրում էր օգնականի հրահանգներն ու մոդելը — այսինքն լուռ հետ էր գլորում ցանկացած փոփոխություն հաջորդ դեպլոյի ժամանակ։ Այժմ այն միայն ստեղծում է օգնականին, եթե նա բացակայում է։ Բազայում եղածը գիտակցաբար նոր մատուցվող հրահանգով կամ կանխադրված մոդելով փոխարինելու համար դիր PLATFORM_ASSISTANT_RESEED=1 մեկ դեպլոյի համար և նորից հանիր (տես docs/DEPLOYMENT.md)։

AI մոդելներ (/platform/ai-models)

Պարզ բառերով. մոդելների միակ ցանկը, որից ընտրում են բոլոր կազմակերպությունների գործակալները, և միակ տեղը, որտեղ այն կարելի է խմբագրել։

intelligence բազայի ModelConfig տողերը գլոբալ են — մեկ ընդհանուր կատալոգ, ոչ թե պատճեն յուրաքանչյուր կազմակերպության համար։ Ընթերցումը բաց է ցանկացած մուտք գործածի համար. գործակալի ձևը պարտավոր է ցանկը առաջարկել բոլոր նրանց, ովքեր կարգավորում են գործակալներ, իսկ մոդելների անվանումները զգայուն չեն։ Գրառումն ապրում է platform-model-configs.controller.ts-ում՝ platform/model-configs հասցեում, PlatformAccessGuard-ի և platform:ai_models:manage-ի հետևում — իր սեփական բանալին 17.09.2026-ից, և այն P4P Admin-ն ունի։ Մինչ այդ բանալին ընդհանուր էր AI օգնականների հետ, այն տրամաբանությամբ, որ օգնականը կարգավորողը և նրա հետևում կանգնած մոդելը ուղղողը նույն մարդն է։ Պարզվեց, որ դրանք տարբեր մարդիկ են. կատալոգը վարելը ամենօրյա սպասարկում է, իսկ այն, ինչ օգնականն ասում է բոլոր աշխատատարածքներին, վերաշարադրելը՝ մեկ աստիճան բարձր։

Բանալին, որով ամեն ինչ աշխատում է, նշվում է այս էջի վերևում, ոչ թե ֆայլում։ Մինչև 17.09.2026-ը այն ապրում էր միայն OPENROUTER_API_KEY-ում, ուստի փոխելը նշանակում էր ssh և վերագործարկում։ Հիմա այն պահվում է գաղտնագրված և նշվում է այստեղ՝ platform:ai_key:manage իրավունքի հետևում, միայն Super Admin-ի և Owner-ի համար, որովհետև դա ամբողջ տեղակայման վճարային հասանելիությունն է, և դրանով աշխատում են բոլոր տարածքները՝ առանց սեփական բանալու։ Միջավայրի փոփոխականը միայն սերմ է. կարդացվում է մեկ անգամ՝ առաջին գործարկման ժամանակ, երբ բանալի դեռ չկա, և այլևս երբեք, ուստի այստեղ հեռացված բանալին մնում է հեռացված։ Բանալին հետ ցույց չի տրվում — քարտը հայտնում է միայն՝ նշված է այն, թե ոչ, և երբ է փոխվել։

Այստեղի ամեն փոփոխություն գրվում է աուդիտի մատյան՝ որպես ai_model.created, ai_model.updated կամ ai_model.withdrawn, AI մոդելներ ֆիլտրով։ Ավելացել է բանալու հետ և նույն պատճառով. մոդելը հանելիս այն ընտրած ամեն գործակալ ընկնում է հաջորդ գործարկման ժամանակ, իսկ հիմա սա ամենօրյա աշխատանք է, ոչ թե Super Admin-ի գործողություն — ուրեմն «ով է հանել» հարցը պետք է պատասխան ունենա։ Եթե մատյանում գրառումը չի ստացվում, փոփոխությունը չի մնում. այն հետ է գլորվում, և էկրանը հայտնում է սխալի մասին, փոխանակ թողնի փոփոխություն, որի համար պատասխանատու չկա։

Մինչև 15.09.2026 այդ գրառումը փակված էր կազմակերպության մակարդակի ai:agents:manage-ով, այսինքն՝ ցանկացած կազմակերպության ադմինիստրատոր կարող էր վերանշանակել կամ հանել այն մոդելը, որից օգտվում էին բոլոր մյուսները։

Մոդելի ընտրությունը։ Երկխոսությունը կարդում է OpenRouter-ի սեփական մոդելների ցանկը, ընդ որում կարդում է սերվերը (GET /platform/model-catalogue, քեշը՝ տասը րոպե), ոչ թե դիտարկիչը. openrouter.ai-ն 403 է պատասխանում որոշ տարածաշրջաններից, որտեղից կառավարվում է հարթակը, իսկ պորտալի Content-Security-Policy-ն այն չի նշում։ Նույն ցանկը ստուգվում է պահպանելիս. OpenRouter-ի իդենտիֆիկատորը, որը չկա դրանում, մերժվում է։ Հենց դա կկանգնեցներ qwen3.8-27b:free,-ի (առանց արտադրողի նախածանցի, վերջում ստորակետով) պահպանումը 21.09.2026-ին։ Տողը, որի իդենտիֆիկատորն արդեն հանված է, դեռ կարելի է անջատել կամ վերանվանել. ստուգվում է միայն փոխված իդենտիֆիկատորը։ Եթե ցանկը ընդհանրապես չի կարդացվում, դաշտը դառնում է տեքստային, և պահպանումն անցնում է առանց ստուգման. «անհայտը» նույնը չէ, ինչ «արգելվածը»։ Մյուս մատակարարների ցանկը հարթակը չի կարող կարդալ (նրանց բանալիները պատկանում են տարածքներին), ուստի նրանց իդենտիֆիկատորները մուտքագրվում են ձեռքով։ Մատակարարն ինքը չորս արժեքներից մեկն է (openrouter, anthropic, openai, google), որովհետև նա որոշում է՝ մոդելը որ API-ով է կանչվում և ում բանալիով։

Ինչու է այս էջն ընդհանրապես պետք։ Մատակարարը կարող է ցանկացած պահի հանել մոդելի իդենտիֆիկատորը, և հանված իդենտիֆիկատորը սխալ չի տալիս — հարցումն անցնում է և վերադարձնում դատարկություն։ Հարթակի բոլոր օգնականները լռում են, և ոչ մի գրանցամատյան չի ասում՝ ինչու։ Այդպես եղավ 15.09.2026-ին ամիսներ առաջ ցանված անվճար մոդելի հետ, և միակ դեղը սերմնացանի խմբագրումն էր՝ հետագա տեղակայմամբ։

Ինչ չկա ձևում. բազային հասցեի փոխարինումը։ Այն որոշում է, թե ուր է գնում հարթակի ընդհանուր բանալին, և սահմանվում է միայն բազայում։ Տես docs/ai/ADR-001-ai-platform-architecture.md, Որոշում 14։

Այս մոդուլի թեստավորում

scripts/e2e/menu/platform-admin.mjs-ը (23 ստուգում) գործարկում է այս մոդուլի հիմնական հոսքերը սկզբից մինչև վերջ և սահմանում lastVerified-ը վերևում, գումարած մեկ միավոր-թեստի ֆայլ ամեն էջի համար (apps/portal/pages/platform/*.test.ts), ինչպես դրանք ավելացվում են՝ էջ առ էջ, առանձին փուլային ջանքով.

• Dashboard — apps/portal/pages/platform/dashboard.test.ts, 6 թեստ — ծածկում է, թե հանգույցի որ քարտերն ու հարցումներն են փակված որ read-իրավունքով, յուրաքանչյուր քարտի իրական «ընդհանուր/ենթաբազմություն» հաշվարկի բաժանումը, «Վերջին ակտիվություն» վահանակի կարիքը ԵՐԿՈՒ պայմանից՝ platform:audit:read ԵՎ գոնե մեկ գրառում, և չքարտեզագրված աուդիտի գործողության կոդի արտապատկերումը իր իսկ հում կոդով, ոչ թե դատարկ պիտակով. platform-admin.mjs-ն նաև հաստատում է, որ /platform-ը իրականում տանում է դեպի /platform/dashboard՝ իրական թվերով, ոչ միայն որ URL-ը պարունակում է «/platform»։
• Organizations — apps/portal/pages/platform/organizations/{index,[id]}.test.ts, 16 թեստ — որոնման/տեսակի/կարգավիճակի/անդամակցության/սեփականատիրոջ ֆիլտրերը, «քոնն է» կրծքանշանի սեփական անդամակցության ստուգումը, slug-ի auto-derive վարքագիծը name-ից մինչև առաջին ձեռքով խմբագրումը և ստեղծման հաջող/ձախողված ուղիները՝ ցուցակի վերբեռնումով և useCurrentUser-ի թարմացումով, «Take ownership»-ի սեփական հասանելիության կանոնը (միայն SUPER_ADMIN, ոչ իր համար, միայն մեկ այլ OWNER-ի տողի վրա) և դրա երկքայլ «մուտքագրեք ճշգրիտ անունը» գեյթը, և ապրանքի բաժանորդագրության փոխարկման POST/PATCH ճյուղավորումը (REACTIVATABLE_STATUSES). platform-admin.mjs-ը լրացվել է բաժանորդագրության իրական տրամադրմամբ կազմակերպության մանրամասների էջից — այս ամբողջ e2e հավաքածուում բաժանորդագրությունների առաջին կենդանի փորձարկումը։
• Users — apps/portal/pages/platform/users/{index,[id]}.test.ts, 18 թեստ — որոնման/կարգավիճակի/դերի/աշխատավայրերի ֆիլտրերը, դերի ֆիլտրի տարբերակները՝ բխեցված բեռնված օգտատերերի սեփական դերերից (առանց կրկնության, դասավորված), գործողությունների սեփական տողի պաշտպանությունը (երբեք չի առաջարկվում սեփական տողի վրա, բացի platform:users:manage-ից), ջնջման հաստատման հաջող և ձախողված ուղիները, «Remove from platform staff»-ի սեփական հասանելիության կանոնը (SUPER_ADMIN կամ Owner, թիրախն իրականում պետք է լինի platform staff), սեփականատիրոջ փոխանցման կոճակի կանոնը (միայն ընթացիկ Owner, թիրախը՝ platform staff, որը դեռ չունի P4P Owner) և երկխոսության հաջողության/ձախողման վարքագիծը, նշանակելի դերերի ցանկը, որը միշտ բացառում է P4P Owner-ը և բացառում է P4P Super Admin-ը, եթե դուք Owner չեք, և saveRoles-ի սեփական նշանակում/չեղարկում diff-ը (հարցումն ուղարկվում է միայն իրականում փոփոխված դերերի համար). platform-admin.mjs-ը լրացվել է իրական «նշանակել դեր → չեղարկել platform staff» ցիկլով այն հաշվի վրա, որը testStaff/acceptStaffInvite-ն արդեն ստեղծում են — մանրամասների էջի սեփական փոփոխող գործողությունները կենդանի ծածկույթ չունեին մինչև այս փուլը։ Միտումնավոր ՉԻ գործարկում «Transfer ownership»-ը կենդանի — ոչ թե սխալ է, այլ միտումնավոր բաց թողնված կործանարար ուղի (սերմային SUPER_ADMIN-ի սեփական Owner դերի փոխանցումը միանգամյա հաշվի, առանց ավտոմատացված վերադարձի ուղու)։
• Roles + Products — apps/portal/pages/platform/{roles,products}/index.test.ts, 18 թեստ — «սկզբում համակարգային, ապա կասկածելի ալֆաբետային» դասավորությունը, «թոփ-3 իրավունք, ապա "+N ևս"» կրծքանշանների կրճատումը, Duplicate-ի հասանելիությունը նույնիսկ համակարգային դերի վրա, մինչդեռ Edit/Delete-ը պահանջում են ոչ-համակարգային դեր, թույլտվությունների դիտման երկխոսության աշխատանքը, ապրանքների որոնումը name/code/description-ով, գործողությունների մենյուի իրավունքի սահմանափակումը, խմբագրման երկխոսության նախալրացումը ընթացիկ տողից, և հաջող/ձախողված PATCH-ը թե՛ խմբագրման ձևի, թե՛ ակտիվացման փոխարկիչի համար. platform-admin.mjs-ը լրացվել է իրական «ապաակտիվացնել → կրկին ակտիվացնել» ցիկլով Products էջում — այս էջի սեփական իրական գործառնական լծակը (ըստ նրա իսկ կոդի մեկնաբանության), որը կենդանի ծածկույթ չուներ մինչև այս փուլը, վերականգնվում է հետ Active վիճակի, որպեսզի իրական սերմային platform ապրանքը չմնա անջատված։ «Duplicate»-ը ինքնին կենդանի չի գործարկվում — այն ուղարկում է հենց նույն էնդփոինթը, որը կասկածելի դերի ստեղծման գոյություն ունեցող ստուգումն արդեն վարժեցնում է, պարզապես տարբեր կերպ նախալրացված ձևով։
• Staff — apps/portal/pages/platform/staff/index.test.ts, 7 թեստ — որոնման/կարգավիճակի/դերի ֆիլտրերը, դերի ֆիլտրի տարբերակները՝ բխեցված բեռնված անձնակազմի սեփական դերերից, և այն, որ «Invite to platform staff»-ը պահանջում է հենց platform:users:invite (ոչ թե ընդհանուր platform:users:manage)։ Գրվել է, երբ այդ դարպասը դեռ կոշտ կոդավորված isSuperAdmin || isOwner/SuperAdminOrOwnerGuard զույգն էր — փոխանցվել է սովորական իրավունքին 2026-08-13 (տես Հրավերներ հարթակի անձնակազմ վերևում); SUPER_ADMIN-ը/P4P Owner-ը դեռ ունեն այն լռելյայն, պարզապես այլևս ոչ որպես կոշտ կոդավորված հատուկ դեպք։ platform-admin.mjs-ն արդեն ծածկել է հրավեր + ընդունում կենդանի ավելի վաղ փուլում — նոր e2e այստեղ պետք չեղավ։
• Հարթակի թիմի հրավերի ընդունում (/platform-staff-invitations/[token]) — apps/portal/pages/platform-staff-invitations/[token].test.ts, 11 թեստ — անվավեր/ժամկետանց հրավերի բեռնման սխալ, դերերով vs. առանց դերերի ամփոփ տեքստը, հաշվի անհամապատասխանություն + ելք, մեկ սեղմումով ընդունում հաջողության/ձախողման դեպքում արդեն մուտք գործած ճիշտ հաշվի համար, գաղտնաբառով մուտք + ընդունում (ներառյալ այս հրավերին հատուկ «սխալ գաղտնաբառ» հաղորդագրությունը), առանց գաղտնաբառի հաշվի պարզ «մուտք գործիր այլուր» հրահանգը (գաղտնաբառի դաշտն ընդհանրապես չի ռենդերվում — միտումնավոր ավելի պարզ հոսք, քան կազմակերպության հրավերի էջի ներկառուցված գաղտնաբառի վերականգնման կոճակը, տես Հրավերի ընդունում), և գրանցման ձևի լռելյայն վարքագիծը՝ ուղարկման հաջողությամբ/ձախողմամբ։ Նոր e2e ֆայլ scripts/e2e/menu/platform-staff-invitation-accept.mjs (6 ստուգում, 2026-08-12) ծածկում է երեք ճյուղերը, որոնց platform-admin.mjs-ի սեփական testStaff/acceptStaffInvite-ը չի հասնում (այդ զույգը միշտ անցնում է միայն նոր օգտատիրոջ գրանցման ուղով)՝ մեկ սեղմումով ընդունում արդեն մուտք գործած հաշվի կողմից, հաշվի անհամապատասխանության դարպասը, և գաղտնաբառով մուտք գոյություն ունեցող, բայց մուտք չգործած հաշվի համար։ Այս ֆայլը գրելիս գտնվեց իրական կառուցվածքային տարբերություն կազմակերպության հրավերի էջից՝ այս էջն ընդհանրապես չունի չեզոք «Accept invitation» դարպասի կոճակ — չմուտք գործած այցելուն ուղղակիորեն ընկնում է համապատասխան ձևի վրա, առանց միջանկյալ սեղմումի։
• Audit log — apps/portal/pages/platform/audit/index.test.ts, 11 թեստ — հարցման լռելյայն պարամետրերը (limit/offset/order: desc), յուրաքանչյուր ֆիլտրի սեփական վերահարցման պարամետրերը, ներառյալ from/until ամսաթվային միջակայքի վավերացումը, որը արգելափակում է վատ հարցումը դեռ չուղարկված, pagination-ի offset/limit մաթեմատիկան և էջ 1-ին վերադարձնելու վարքագիծը, և auditChanges/auditExtraMetadata/ auditValueLabel-ի իրական վերլուծման կանոնները (իրական metadata.changes diff-ը առաջնահերթություն ունի metadata-ի մնացած ամեն ինչի հում key/value dump-ի նկատմամբ), և կատարողի/օբյեկտի լուծված անունների ռենդերը՝ յուրաքանչյուր id-ի կողքին պատճենելու կոճակով — հում տիպ + UUID-ի հետնթացով, երբ backend-ը անուն չի լուծել։ platform-admin.mjs-ն արդեն ծածկել է գրառումների ռենդերը կենդանի ավելի վաղ փուլում։

Սա փակում է միավոր-ծածկույթը այս մոդուլի փաստաթղթավորած /platform/*-ի յուրաքանչյուր էջի համար։ platform/notifications.vue-ն (երթուղավորվում է /platform/-ի տակ, բայց փաստաթղթավորվում է Notifications-ում, ոչ այստեղ) ստացավ իր սեփական փուլը նույն ջանքի մեջ — ներառյալ իրական, նշանակալի հայտնաբերված սխալ — տես այդ մոդուլի սեփական «Այս մոդուլի թեստավորում» բաժինը. platform-admin.mjs-ի 23-ստուգումանոց ընդհանուր թիվը ներառում է նաև նրա 5 ստուգումները։

Հայտնաբերված, չուղղված (հավելվածի կոդ, այս թեստավորման փուլի շրջանակից դուրս — ամբողջ պատմության համար տես scripts/e2e/README.md-ի սեփական նկարագրությունը). կազմակերպությունների ցուցակի «քոնն է» անդամակցության կրծքանշանն ու DataTable-ի սեփական վերջափակող մանրամասների հղումն ունեն բառացիորեն նույն մատչելի անունը՝ «Open workspace» (platform.organizations.openWorkspace և common.openWorkspace — երկու տարբեր i18n բանալի, որոնք պատահաբար լուծվում են նույնական անգլերեն տեքստի), բայց տանում են երկու տարբեր վայրեր (մուտք գործել աշխատավայր որպես անդամ ընդդեմ բացել platform-admin մանրամասների տեսքը)։ Երևում է միայն այն տողում, որտեղ դիտող SUPER_ADMIN-ը նաև պատահաբար անդամ է — ճիշտ է ցանկացած կազմակերպության համար, որը նա հենց նոր ինքն է ստեղծել, քանի որ ստեղծողը դառնում է դրա OWNER-ը։

Հայտնաբերված, չուղղված (հայտնի սխալի 5-րդ դեպքը, առաջին անգամ հայտնաբերվել է 2026-07-ին team/departments/[id]/roles.vue-ի սեփական ջնջման հաստատման երկխոսության վրա — ամբողջ պատմության և մյուս 3 դեպքերի համար տես scripts/e2e/README.md-ի այս փուլի նկարագրությունը). platform/users/index.vue-ի ջնջման հաստատման երկխոսությունն օգտագործում է AlertDialogAction, որն ունի սեփական ներքին click-փակման հանդիսատես, որը reka-ui-ն միացնում է այս հավելվածի սեփական @click="confirmDelete"-ի հետ նույն կոճակի վրա — Delete-ի իրական կտտոցը ձախողված ջնջման ընթացքում փակում է երկխոսությունն անմիջապես, անկախ ասինքրոն արդյունքից, ուստի ներկառուցված սխալը երբեք չի արտապատկերվում (թոստը դեռ ցուցադրվում է, քանի որ այն կապված չէ երկխոսության վիճակի հետ)։

Հայտնաբերված, չուղղված (նույն սխալի 6-րդ դեպքը). Delete-ի հաստատման սեփական երկխոսությունը platform/roles/index.vue-ում ունի նույն ձևը — նույն սխալը, նույն հետաձգված ուղղումը նույն պատճառով։

Ավտոմատացմամբ չծածկված, դեռ արժե ձեռքով ստուգել — տես docs/MANUAL_TESTING.md. read/manage իրավունքով փակում յուրաքանչյուր էջի փոփոխող կառավարիչների վրա, SUPER_ADMIN դերի արգելափակում staff հրավերում, platform դերերի սեփականատիրոջ փոխանցման ուղին, և platform:audit:read-ի փակումը հենց Audit Log էջում։