add runtime log views and standardize status dots
ci/woodpecker/push/woodpecker Pipeline was successful

This commit is contained in:
2026-07-09 10:16:25 +09:00
parent f67017623f
commit 3cab64a256
13 changed files with 990 additions and 65 deletions
+57 -18
View File
@@ -10,7 +10,7 @@ The visible menu labels and button labels in the application are Korean. Keep th
- 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, break links, or decommission resources. This includes deletion, removal, cleanup, 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.
- 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`.
@@ -18,30 +18,35 @@ The visible menu labels and button labels in the application are Korean. Keep th
- 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.
## Main Menu Map
- `대시보드`: Shows current platform status, common app status, and license usage.
- `대시보드`: 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 common configuration.
- `런처 > 로그/이벤트`: 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.
- `어플리케이션 > 배포 관리`: Deploys successful releases to the production environment. Releases already successfully deployed are excluded from the default deployable candidates.
- `어플리케이션 > 실행 설정`: Manages runtime environment variables and Secret values. Add/delete actions save immediately.
- `어플리케이션 > 릴리즈 관리`: 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, permissions, SSH keys, and admin status.
- `운영 > 관리자 관리`: 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.
@@ -58,6 +63,17 @@ The following menus are reference-only unless the user explicitly allows enterin
- `새로고침`, 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.
@@ -121,11 +137,10 @@ When the user asks to set up and deploy the launcher, follow this order.
1. In `런처 > 구성요소`, register required launcher components.
2. In `런처 > 소스 관리`, connect launcher components to repositories.
3. In `런처 > 공통 설정`, register launcher common settings.
4. In `런처 > 앱 연결`, connect apps that should appear in the launcher and save their order.
5. In `런처 > 빌드 관리`, run required launcher build jobs.
6. After successful builds, in `런처 > 버전 관리`, register version, minimum supported version, artifact URL, and release notes.
7. Activate the new launcher version only if needed and confirmed.
3. In `런처 > 앱 연결`, connect apps that should appear in the launcher and save their order.
4. In `런처 > 빌드 관리`, run required launcher build jobs.
5. After successful builds, in `런처 > 버전 관리`, register version, minimum supported version, artifact URL, and release notes.
6. Activate the new launcher version only if needed and confirmed.
Forbidden launcher actions:
@@ -133,16 +148,16 @@ Forbidden launcher actions:
- 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.
1. If common settings must change, update `런처 > 공통 설정` first.
2. If launcher app exposure or order changes, update `런처 > 앱 연결`. Do not change app links unless the user explicitly asks.
3. Run the new required build in `런처 > 빌드 관리`.
4. After build success, register or update version, minimum supported version, download artifact, and release notes in `런처 > 버전 관리`.
5. Activate the new version only if needed and confirmed.
1. If launcher app exposure or order changes, update `런처 > 앱 연결`. Do not change app links unless the user explicitly asks.
2. Run the new required build in `런처 > 빌드 관리`.
3. After build success, register or update version, minimum supported version, download artifact, and release notes in `런처 > 버전 관리`.
4. Activate the new version only if needed and confirmed.
Forbidden launcher update actions:
@@ -150,6 +165,7 @@ Forbidden launcher update actions:
- 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
@@ -181,6 +197,7 @@ Build list handling:
- 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
@@ -199,6 +216,7 @@ When the user says "create release", "version up", or "make a release for produc
11. If release status is `대기` or `실행 중`, wait.
12. Open release logs with the row's right-side `...` button.
13. If status becomes `성공`, the release is deployable. If it becomes `실패`, inspect logs first.
14. 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:
@@ -255,6 +273,7 @@ Deployment list handling:
- 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
@@ -266,7 +285,8 @@ For environment variable or Secret additions/edits, follow this order.
4. If the value is secret, select the Secret option.
5. Click `설정값 추가`. This saves immediately. Do not expect a separate apply button.
6. The `접속 설정` area is for service port, external path, and ingress-related values.
7. Do not expect automatic rollout after saving settings. The user may restart from app management or explicitly request a restart.
7. Deleting a setting value or ingress connection opens a confirmation modal. PageAgent must not confirm deletion.
8. Do not expect automatic rollout after saving settings. The user may restart from app management or explicitly request a restart.
Common runtime settings:
@@ -316,6 +336,17 @@ Launcher forbidden actions:
- 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.
1. Go to `런처 > 로그/이벤트`.
2. Select `런처 백엔드` for API/provision/login/update issues.
3. Select `런처 DB` only when database workload logs or events are needed.
4. Choose a running workload from the left list.
5. Use the `로그` tab for workload logs and the `이벤트` tab for Kubernetes events.
6. 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.
@@ -328,6 +359,14 @@ If the user asks to delete, remove, or decommission an app, PageAgent must not e
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.