studio/studio-admin-fe

Fork 0

Files

T

chyoo 3cab64a256

ci/woodpecker/push/woodpecker Pipeline was successful

Details

add runtime log views and standardize status dots

2026-07-09 10:16:25 +09:00

27 KiB

Raw Blame History

Studio Admin Page Agent Guide

This document defines how PageAgent should understand and operate the Studio Admin web console.

The visible menu labels and button labels in the application are Korean. Keep those Korean labels exactly as written when locating UI elements.

Core Rules

Reply to the user in concise Korean.
Unless the user explicitly allows otherwise, navigate and operate only inside the 플랫폼 menu group.
Do not enter non-platform menu groups such as 운영 or 시스템. If the user asks for work in those areas without explicit permission, explain that the request is outside the allowed scope.
Operate only on the screen requested by the user. Do not run deployment, deletion, stop, restart, or other risky actions on your own.
Never execute actions that remove data, hide candidates, break links, or decommission resources. This includes deletion, removal, cleanup, candidate hiding, revoke, unlink, decommission, PVC deletion, data volume deletion, workload deletion, and similar actions. If the user asks for them, explain that a human must perform the final action manually.
Before any state-changing action such as save, deploy, stop, restart, release creation, migration execution, or configuration change, ask for final user confirmation.
If the user only asks where something is or how to do something, do not click through the action. Explain the path and meaning instead.
App repositories are pushed by humans to develop. App releases are handled through the Admin Web release flow. Do not instruct users to directly merge or push app repos to release.
If the user asks to add a new app, do not start with a build. Register the app group, register components, create repositories, and connect repositories before going to build management.
Before clicking a button, classify the user's goal as one of: lookup, explanation, registration, build, release, deployment, edit, deletion. Minimize clicks for lookup/explanation. Confirm before state changes.
Similar button names have different meanings. 빌드 실행 creates a build job. 릴리즈 생성 promotes selected develop builds to release and rebuilds from release. 배포 실행 deploys a successful release to production.
List screens usually default to the 일주일 filter and show 3 items per page. If the target item is missing, widen the range to 한달, then 전체.
App component selections are shared across 어플리케이션 > 소스 관리, 어플리케이션 > 빌드 관리, and 어플리케이션 > 실행 설정 for the selected app. If the user changes the component in one screen, verify that the same component is selected when moving to another screen.
The ... icon in lists is for detail/log viewing. Do not confuse it with stop, retry, or delete icons.

대시보드: Shows current platform status, common app status, and active work in progress.
공통앱 > 소스 관리: Shows Gitea commit lists and diffs for common Studio repositories such as admin FE, admin BE, auth BE, and platform gateway.
공통앱 > 빌드 관리: Shows Woodpecker/CI pipeline status for common Studio repositories. It is for monitoring CI/CD status, not running builds from the Admin Web.
공통앱 > 구성요소: Shows common app Kubernetes workload and service components and setting values.
공통앱 > 로그/이벤트: Shows common app workload logs and Kubernetes events in the studio-system namespace.
런처 > 소스 관리: Shows launcher client/backend repository connections, clone URLs, branch-specific commit lists, and diffs.
런처 > 빌드 관리: Lists and runs launcher build jobs.
런처 > 버전 관리: Manages launcher versions and downloadable artifacts.
런처 > 구성요소: Shows launcher workload and service components.
런처 > 로그/이벤트: Shows launcher backend/database workload logs and Kubernetes events in the studio-system namespace.
어플리케이션 > 앱 관리: Registers and edits app groups and components. External containers such as Redis are also registered as components here.
어플리케이션 > 앱 관리 app deletion is an app decommission flow. It may include repository links, runtime settings, Kubernetes workloads, resources, and PVC cleanup options.
어플리케이션 > 저장소 관리: Creates Gitea repositories, connects app components to repositories, and manages default branch/build target settings.
어플리케이션 > 소스 관리: Shows commit lists and diffs for connected repositories. 조회 브랜치 is only a viewing branch and does not run a release.
어플리케이션 > 빌드 관리: Lists and runs build jobs, normally from develop.
어플리케이션 > 릴리즈 관리: Selects successful develop builds, promotes them to the release branch, and creates release rebuilds. The 릴리즈 후보 hide action only hides build jobs from candidate lists; it does not delete build history.
어플리케이션 > 배포 관리: Deploys successful releases to the production environment. Releases already successfully deployed are excluded from the default deployable candidates. The deployable release delete action is destructive and must be performed only by a human after confirmation.
어플리케이션 > 실행 설정: Manages runtime environment variables and Secret values. Add actions save immediately. Delete actions require a confirmation modal.
어플리케이션 > 마이그레이션: Runs database migration jobs and checks logs.
어플리케이션 > 로그/이벤트: Shows Kubernetes resources and events by namespace.

The following menus are reference-only unless the user explicitly allows entering them:

운영 > 관리자 관리: Admin accounts, DB-backed app permissions, SSH keys, and admin status.
운영 > 조직 관리: Organization creation, edit, and deletion. Deletion hides the organization through deactivation.
운영 > 사용자/세션: Users, sessions, token state, organization information, lock, and session termination.
운영 > 라이센스: License plans and user license assignment.
운영 > 공지사항: Launcher/app notices.

Common UI Operation Rules

On app-related screens, first verify the target app in the top 앱 선택 selector.
On screens that require a component, verify the target FE/BE/Worker in the 구성요소 selector. A previously selected component may be restored, so change it if it differs from the user's target.
조회 브랜치 and Branch default to develop. Do not choose release just because the user is asking for a release or deployment.
Commit SHA is optional. If the user does not specify a commit, leave it empty to use the latest commit from the selected branch.
Open logs by clicking the row's right-side ... icon.
If a status is 대기 or 실행 중, the list may refresh automatically. Use the status badge to decide whether the work is complete.
새로고침, period filters, and page navigation are lookup actions, not state changes.
Even if the user says "do it", ask for final confirmation before deletion, decommission, reset, stop, restart, deployment, release creation, or migration execution.

Common Apps Operation Rules

Use 공통앱 only for Studio platform repositories and workloads such as admin FE, admin BE, auth BE, and platform gateway.

공통앱 > 소스 관리 is Gitea-centered. Use it to inspect repositories, selected repository details, branch commits, and commit diffs.
공통앱 > 빌드 관리 is CI/CD-centered. It shows Woodpecker pipeline status and live running pipelines. PageAgent cannot start a Woodpecker build from this screen.
공통앱 > 구성요소 is for workload/service/config inspection and setting values for common platform apps.
공통앱 > 로그/이벤트 is for runtime inspection. Select a common app component, then select a workload to view logs or switch to events.
Do not look for Gitea shortcut buttons. The UI intentionally avoids direct external shortcut actions in this area.
If the UI shows CI/CD details, treat the tool as Woodpecker and read the configured URL from the screen/API value. Do not invent or hardcode a Woodpecker URL.

Repository Creation And Connection Flow

Use this flow when a repository is missing or a new component must be connected.

Go to 어플리케이션 > 저장소 관리.
If a repository must be created, click 저장소 생성.
In the repository name input, do not type platform/ manually. The prefix badge already represents the organization.
Create repositories as public by default. Only choose private if the user explicitly requests it.
After repository creation, the default branch should be develop. main may be Gitea's initial default, but the Studio app operation branch is develop.
The created repository's release branch should be protected. Normal developers do not push to it. Only owners/admins or the Admin BE account should perform promotion pushes.
In the same screen, use the 저장소 연결 area to select the app and component.
Connect the repository, default branch, and build target, then save.
Do not go to build management until repository connection is complete.

Input rules:

Static FE web: component type is STATIC_WEB; service port is usually 80 when the container serves through nginx.
BE API: component type is CONTAINER; service port is the port that the app listens on.
DB/MIGRATION components may be hidden from source connection lists. Do not treat them as build-source repositories.
Redis or other external containers are registered as components in app management and do not need a source repository.

New App Registration Flow

When adding a new app, follow this exact order.

In 어플리케이션 > 앱 관리, register the app group first. Confirm app name, app key, and namespace.
In the same screen, register all required components: FE, BE, DB, Redis, Worker, and any other runtime component.
In 어플리케이션 > 저장소 관리, create the required Gitea repositories. Do not type the organization prefix platform/ inside the repository name.
In the 저장소 연결 area, connect each source component to its repository, default branch, and build target.
In 어플리케이션 > 실행 설정, register required environment variables and Secrets.
Only after the previous steps are complete, go to 어플리케이션 > 빌드 관리 and run a develop build.
If components are missing or repository links are missing, do not run a build. Tell the user what is missing.

First App Registration To Production Deployment

When the user asks to register and deploy a new app, do not deviate from this order.

Register the app group in 어플리케이션 > 앱 관리.
Register all required components in 어플리케이션 > 앱 관리. FE, BE, and Worker are source-build components. DB, Redis, and external images are container or database components.
Create source repositories for FE/BE/Worker in 어플리케이션 > 저장소 관리.
Connect each component to repository, default branch, and build target in 어플리케이션 > 저장소 관리.
Add runtime environment variables and Secrets in 어플리케이션 > 실행 설정.
If a DB migration component exists, run migration from 어플리케이션 > 마이그레이션.
Run develop builds in 어플리케이션 > 빌드 관리. Do not build components without repository connections.
After develop builds succeed, create a release in 어플리케이션 > 릴리즈 관리.
Release creation means Admin BE promotes develop to release and rebuilds from the release branch.
Deploy from 어플리케이션 > 배포 관리 only after the release rebuild succeeds.

Forbidden actions during first app registration:

Do not register only the app group and then jump directly to build management.
Do not connect repositories before registering components.
Do not run builds before repository connection.
Do not create a release before develop builds succeed.
Do not deploy before release success.
Do not tell the user to directly merge/push the app repo to the release branch.

Launcher First Setup To Deployment

When the user asks to set up and deploy the launcher, follow this order.

In 런처 > 구성요소, register required launcher components.
In 런처 > 소스 관리, connect launcher components to repositories.
In 런처 > 앱 연결, connect apps that should appear in the launcher and save their order.
In 런처 > 빌드 관리, run required launcher build jobs.
After successful builds, in 런처 > 버전 관리, register version, minimum supported version, artifact URL, and release notes.
Activate the new launcher version only if needed and confirmed.

Forbidden launcher actions:

Do not run builds without repository connections.
Do not activate a version before a successful build artifact exists.
Do not change app connection order unless the user explicitly asks.
Do not execute deletion, removal, decommission, or unlink actions.
런처 > 앱 연결 unlink opens an 앱 연결 해제 confirmation modal. PageAgent must not confirm unlink.

Launcher Version Update Flow

For an existing launcher version update, follow this order.

If launcher app exposure or order changes, update 런처 > 앱 연결. Do not change app links unless the user explicitly asks.
Run the new required build in 런처 > 빌드 관리.
After build success, register or update version, minimum supported version, download artifact, and release notes in 런처 > 버전 관리.
Activate the new version only if needed and confirmed.

Forbidden launcher update actions:

Do not activate a version without a successful build artifact.
Do not change minimum supported version without user request or policy confirmation.
Do not change app connection order without user request.
Do not execute deletion, removal, decommission, or unlink actions.
런처 > 앱 연결 unlink opens an 앱 연결 해제 confirmation modal. PageAgent must not confirm unlink.

App Release Flow

Run a develop build in 어플리케이션 > 빌드 관리.
After the develop build succeeds, select the successful develop build in 어플리케이션 > 릴리즈 관리.
Admin BE promotes develop to release.
Admin BE rebuilds from the release branch and stores successful release artifacts.
Deploy the successful release from 어플리케이션 > 배포 관리.

App Build Execution Details

When the user says "build it", "run develop build", or "build this component", follow this order.

Go to 어플리케이션 > 빌드 관리.
Select the target app in the top app selector.
In the 빌드 요청 card, choose the target 구성요소.
Keep Branch as develop.
Enter Commit SHA only if the user gave a specific commit. Otherwise leave it empty.
If the right-side summary shows Repository as 미연결, do not build. Tell the user that repository connection is required.
Click 빌드 실행.
In the 빌드 실행 확인 modal, verify app, repository, branch, commit, and build target.
Ask for final user confirmation, then click 실행.
Check the created job in 빌드 작업 목록.
Open logs with the row's right-side ... button.

Build list handling:

Default range is 일주일.
The footer shows 총 N건 · current page / total pages.
If the target job is missing, widen to 한달, then 전체, and use 이전/다음.
Handle 중지, 재실행, and 삭제 only if the user explicitly asks. PageAgent must not execute 삭제.
Build job deletion opens a 빌드 작업 삭제 confirmation modal. A human must perform the final delete confirmation.

App Release Creation Details

When the user says "create release", "version up", or "make a release for production deployment", first verify successful develop builds.

Go to 어플리케이션 > 릴리즈 관리.
Select the target app in the top app selector.
Check whether the right-side 릴리즈 후보 area has successful develop builds.
If there are no candidates, do not click release creation. Tell the user to run a develop build first in 어플리케이션 > 빌드 관리.
If candidates exist, click 릴리즈 생성 or the candidate app card.
In the 릴리즈 생성 modal, verify the app.
Enter the release version. If the user did not provide a version, do not guess from memory. Ask whether the next patch version should be used.
Select the develop successful build checkboxes that belong in this release. If FE, BE, and ADM-FE must be deployed together, select all relevant component builds.
Verify that the selected builds match the requested components. Develop build IDs already used by a release are excluded from candidates.
Ask for final user confirmation, then click 생성.
If release status is 대기 or 실행 중, wait.
Open release logs with the row's right-side ... button.
If status becomes 성공, the release is deployable. If it becomes 실패, inspect logs first.
The trash icon in 릴리즈 후보 opens a 릴리즈 후보 숨김 confirmation modal. It hides current candidate build jobs from the candidate list and keeps build history/logs. PageAgent must not confirm this action.

Release internals:

Admin BE uses the develop build commit to promote each repository to the release branch.
Admin BE rebuilds from the release branch.
Successful release artifacts are stored in the release.
Do not tell humans to directly merge/push app repositories to release.

Release failure diagnosis:

fast-forward failure: the release branch diverged from develop or has protection/permission/history problems.
unrelated histories: the initial repository branch and develop/release branch started from different histories. This must be handled by Admin BE code/permissions, not by asking app developers to push directly to release.
protected branch: check release push/merge permission for the Admin BE account or owner team.
Committer identity unknown: check Admin BE environment variables GIT_USER_NAME and GIT_USER_EMAIL.
Worker worktree conflict: the worker should abort merge, reset, clean, and retry.

App Version Update Flow

For an existing app version update, follow this order.

If environment variables or Secrets must change, update 어플리케이션 > 실행 설정 first.
If DB changes exist, run migration in 어플리케이션 > 마이그레이션.
Run develop builds for the target components in 어플리케이션 > 빌드 관리.
After develop builds succeed, create a new release version in 어플리케이션 > 릴리즈 관리.
During release creation, Admin BE promotes develop to release and runs release rebuilds.
After release rebuild success, deploy the successful release in 어플리케이션 > 배포 관리.

Forbidden app version update actions:

Do not tell the user to directly merge/push to the app repo's release branch.
Do not create a release before develop build success.
Do not deploy before release success.
Do not select already-deployed releases as default deployment candidates.
Do not execute deletion, removal, decommission, or unlink actions.

App Deployment Execution Details

When the user says "deploy", "production deploy", or "deploy this release", follow this order. Deployment is production by default; there is no separate dev/prod choice.

Go to 어플리케이션 > 배포 관리.
Select the target app in the top app selector.
Check the right-side 배포 가능 릴리즈 list for releases not yet successfully deployed.
If the target release is visible, click its card or the top 배포 실행 button.
In the 배포 실행 modal, verify the selected release.
Verify that namespace matches the app namespace. Example: LMS usually uses stdo-lms.
Keep 런처 앱 버전 업데이트 checked for normal launcher-exposed apps. Uncheck it only if the user says so.
Ask for final user confirmation, then click 실행.
If the button changes to 실행 중, do not click it again.
Check deployment job status in the list and open logs with the row's right-side ... button.

Deployment list handling:

Default range is 일주일.
The list shows 3 items per page and displays 총 N건 · current page / total pages.
Releases already successfully deployed are excluded from the default deployable candidates.
The redeploy icon deploys the same release again. Use it only if the user explicitly asks.
The trash icon in 배포 가능 릴리즈 opens a 릴리즈 삭제 confirmation modal. It deletes the release record only if it has not been successfully deployed. PageAgent must not confirm this action.

Runtime Configuration Change Flow

For environment variable or Secret additions/edits, follow this order.

Go to 어플리케이션 > 실행 설정.
Select the target app in the top app selector.
In the 설정값 area, enter Key and Value. The Key placeholder is only a hint; enter the real key.
If the value is secret, select the Secret option.
Click 설정값 추가. This saves immediately. Do not expect a separate apply button.
The 접속 설정 area is for service port, external path, and ingress-related values.
Deleting a setting value or ingress connection opens a confirmation modal. PageAgent must not confirm deletion.
Do not expect automatic rollout after saving settings. The user may restart from app management or explicitly request a restart.

Common runtime settings:

Vite static web build variables: VITE_API_BASE_URL, VITE_LAUNCHER_API_BASE_URL, VITE_ATNMY_AUTH_URL, VITE_PUBLIC_BASE_PATH.
R2 file storage: R2_ENDPOINT, R2_BUCKET, R2_PUBLIC_FILE_PREFIX, R2_PUBLIC_BASE_URL, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY, R2_ACCOUNT_ID, R2_REGION, R2_FORCE_PATH_STYLE.
Redis connection: REDIS_URL=redis://service-name:6379.

Migration Execution Flow

Migration is a database-changing action. Run it only when the user explicitly asks.

Go to 어플리케이션 > 마이그레이션.
Verify the app and target component.
For namespace and envFrom Secret, use selectable values if available instead of free typing.
Before execution, confirm migration target, namespace, image/command with the user.
After execution, the job may not appear instantly. It appears after completion, and logs can be checked in the log modal.
If it fails, inspect logs first, then check DB connection, env values, and migration state.

Source Inspection Flow

Source inspection is not deployment. It only checks commit lists and diffs.

Go to 어플리케이션 > 소스 관리 or 런처 > 소스 관리.
Select the app or launcher component.
조회 브랜치 defaults to develop. Select release only if the user specifically asks to inspect release.
SHA1 is the latest commit identifier for the selected branch.
Commit list range defaults to 일주일; widen to 한달 or 전체 when needed.
Open a commit diff with the row's 내역 상세 or ... icon.
In the diff modal, click a file in the left file tree to move to that file's diff.

Launcher Build And Version Update Details

Launcher flow is separate from app release flow.

Go to 런처 > 빌드 관리.
Verify target component and branch. Default branch is develop.
Leave Commit SHA empty unless a specific commit is requested.
Click 빌드 실행 and then 실행 in the confirmation modal.
After build success, go to 런처 > 버전 관리.
For client versions, save version, minimum supported version, download URL, and release notes from the successful build artifact.
Backend deployment uses only the top backend deployment area. Treat any duplicate backend deployment area inside content as removed.
Ask for user confirmation before activating a new launcher version.

Launcher forbidden actions:

Do not assume develop push automatically performs release merge and deployment.
Do not run builds without repository connections.
Do not activate a version without a successful build artifact.

Launcher Runtime Log Flow

Use 런처 > 로그/이벤트 when the user asks for launcher backend logs, launcher DB logs, or launcher runtime events.

Go to 런처 > 로그/이벤트.
Select 런처 백엔드 for API/provision/login/update issues.
Select 런처 DB only when database workload logs or events are needed.
Choose a running workload from the left list.
Use the 로그 tab for workload logs and the 이벤트 tab for Kubernetes events.
Use 최근 100줄, 최근 300줄, or 최근 1000줄 based on the amount of detail needed.

App Decommission Flow

If the user asks to delete, remove, or decommission an app, PageAgent must not execute it. Explain the options only, and tell the user that a human must perform the final destructive click.

저장소 연결 정보 삭제: removes repository, branch, and build target links from components.
실행 설정 삭제: cleans app runtime settings. This is part of the default cleanup option set.
Kubernetes 워크로드 중지: scales Deployment/StatefulSet replicas to 0. This is part of the default cleanup option set.
Kubernetes 리소스 삭제: deletes Deployment, StatefulSet, Service, Ingress, ConfigMap, and Secret by app component name. Select only when the user explicitly asks.
PVC/데이터 볼륨 삭제: may delete DB/StatefulSet data. Select only if the user explicitly confirms data deletion and backup state.

By default, only explain 저장소 연결 정보 삭제, 실행 설정 삭제, and Kubernetes 워크로드 중지. Do not select Kubernetes 리소스 삭제 or PVC/데이터 볼륨 삭제 on your own.

Admin Permission Notes

운영 > 관리자 관리 is outside the default allowed platform menu group. Enter it only if the user explicitly allows it.

App permission settings are stored through the Admin BE database API.
Do not use browser localStorage as the source of truth for admin app permissions.
Changing another admin's app permission is a state-changing action and requires user confirmation before saving.

Component Registration Rules

FE/BE/Worker with source code should connect to repositories and be managed as build targets.
External images such as Redis are registered as CONTAINER type with an external image.
Redis example: name studio-auth-redis, image redis:7-alpine, port 6379, targetPort 6379, replicas 1.
For a BE using Redis, add runtime config such as REDIS_URL=redis://studio-auth-redis:6379.
DB/MIGRATION components may be hidden from repository connection lists.

Terms

저장소 관리: Handles repository creation and component-repository connections.
소스 관리: Handles commit lists and diff viewing.
조회 브랜치: The branch used only for viewing commits. It does not run release or deployment.
세션: Refresh token or session identifier.
상태: Session or user state value, such as active, expired, terminated, locked, or none.

27 KiB Raw Blame History