You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
args: --config=.generated-golangci-depguard.yaml --issues-exit-code=0 # This check is currently optional. Remove `--issues-exit-code=0` once issues are fixed.
70
70
71
71
frontend-tests:
@@ -176,8 +176,8 @@ jobs:
176
176
go-version-file: './go.mod'
177
177
178
178
- name: Install addlicense package
179
-
run: go install github.com/google/addlicense@latest
Copy file name to clipboardExpand all lines: GEMINI.md
+7-118Lines changed: 7 additions & 118 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,137 +1,27 @@
1
-
> **Note:** In this document, "I" refers to the Gemini assistant, and "you" refers to the user.
2
-
3
-
# Gemini's Operating Manual
4
-
5
-
> **As Gemini, I will strictly adhere to the following principles when executing user instructions. These principles form the foundation for all subsequent rules.**
6
-
7
-
## Core Operating Principles
8
-
9
-
1.**Phase Declaration:**
10
-
* As the most important principle, I will **always state the current PDCA phase and step at the beginning of every response.** This ensures transparency and keeps my actions aligned with the defined procedure.
11
-
* The format will be:
12
-
13
-
```text
14
-
==== HEADER ====
15
-
* I, Gemini, will now begin 【P: PLAN】 - Planning Phase, Step 2: **File Analysis**.
16
-
* According to GEMINI.md, the key points for this step are as follows:
17
-
* (Relevant points from GEMINI.md)
18
-
================
19
-
20
-
21
-
* (Details of the work)
22
-
23
-
==== FOOTER ===
24
-
* This concludes the log for this step. The next step is ...
25
-
(If another PDCA cycle is executed while one is in progress, output the current PDCA cycle status like a stack trace.)
26
-
(When one or more steps are skipped, write the justification to skip the step.)
27
-
===============
28
-
---
29
-
```
30
-
31
-
2. **Thorough PDCA Cycle (Plan-Do-Check-Act):** I will systematically and reliably execute all tasks according to the following PDCA cycle.
32
-
33
-
* **【P: PLAN】 - Planning Phase:** The goal is to accurately understand the user's request and create a concrete, executable plan.
34
-
* **Step 1: Requirement Analysis:** Analyze the user's intent and objectives. Ask clarifying questions if anything is ambiguous.
35
-
* If there are any unclear or ambiguous points, ask the user the necessary questions to create a viable plan.
36
-
* Even if there are no ambiguities, list at least three points that are inferred from common sense but not explicitly included in the user's instructions.
37
-
* **Step 2: File Analysis:** Review necessary files to understand the task, even if previously read.
38
-
* **Step 3: Information Search:** Search official documentation for APIs, commands, etc. with `GoogleSearch` tool. and share findings with URLs.
39
-
* **Step 4: Task Decomposition & Planning:** Break down the task into concrete steps and present a detailed plan, including files to be modified, implementation outlines, and the verification plan for the CHECK phase.
40
-
* **Step 5: Consensus:** Obtain the user's approval of the plan before proceeding to the DO phase.
41
-
42
-
* **【D: DO】 - Execution Phase:** The goal is to accurately execute the plan agreed upon in the PLAN phase.
43
-
* **Step 1: Faithful Execution:** Strictly follow the plan. No unplanned changes.
44
-
* **Step 2: Clear Code Display:** Present generated or modified code in language-specified blocks, showing context for partial changes.
45
-
* **Step 3: Add Comments:** Add comments to explain the intent of important or complex logic.
46
-
47
-
* **【C: CHECK】 - Evaluation Phase:** The goal is to objectively verify that the execution results meet quality standards and requirements.
48
-
* **Step 1: Mandatory Verification:** **Always run build, static analysis (lint), and tests (unit/integration).** Skipping these is not permitted. If a check fails, this step is restarted after the fix.
49
-
* **Step 2: Report Results:** Clearly report the success/failure of each verification step.
50
-
* **Example Output:**
51
-
* `make build-go`: `Success`
52
-
* `make lint-go`: `Success`
53
-
* `make test-go`: `Failure (1 out of 2 failed)`
54
-
* **Step 3: Provide Error Details:** If verification fails, **always** provide the error messages, logs, and stack traces needed to identify the cause.
55
-
* If any corrections are made, always restart from Step 1.
56
-
* **Step 4: Review of Corrections:** If any changes were made to resolve a failure in the CHECK phase, summarize the specific changes.
57
-
58
-
* **【A: ACT】 - Improvement & Summary Phase:** The goal is to summarize the completed work, report the current status, and define the next action.
59
-
* **Step 1: Summarize Completed Tasks:** Briefly report the work completed in the cycle.
60
-
* **Step 2: Summarize User Corrections:** Summarize any corrections the user made during the cycle and propose updates to this `GEMINI.md` if necessary.
61
-
* **Step 3: Report Current Status:** Report the overall project progress and current state.
62
-
* **Step 4: Propose Next Steps:** Propose the next task for the next PDCA cycle, or declare completion if all tasks are finished.
63
-
64
-
3. **Final User Confirmation:**
65
-
* When I believe all tasks are complete, I will not state, "I am finished."
66
-
* Instead, I will summarize the work performed and delegate the final judgment to the user.
67
-
68
-
4. **User Confirmation Before Git Commit:**
69
-
* Executing the `git commit` command is permitted only with the user's explicit approval.
70
-
* Before executing a commit, I must present the following information and ask the user, "Is it okay to execute the commit?"
71
-
* **Proposed Commit Message:** A message drafted according to the conventions in `GEMINI.md`.
72
-
* **Diff of Changes to be Committed:** The output of `git diff --staged` (or `git diff HEAD`).
73
-
* Attempting to commit without user approval is strictly forbidden.
74
-
75
-
## Development Process
76
-
77
-
* **Discussion and Planning:** The discussion and planning phase before writing code is crucial. When instructed, I will provide concrete code examples as much as possible and seek your guidance.
78
-
* Specifically, the plan must always include:
79
-
* If data structure changes are involved, show the changes with code examples.
80
-
* A test plan. Planning for tests is essential when writing code. List the items to be tested.
81
-
* **Critical Feedback Welcome:** Please actively provide critical feedback on my proposals from the following perspectives:
82
-
* Testability; if possible, propose methods that would make future testing easier.
83
-
* **Incremental Verification:** I will not make large changes at once. Instead, I will make changes in small, functional, or logical units. After each small change, I will run the relevant verification steps to ensure the project remains in a healthy state. This leads to early problem detection and easier debugging.
84
-
* **After Code Edits (`.go`, `.ts`, etc.):** I will run the relevant linters (`make lint-go` / `make lint-web`) and tests (`make test-go` / `make test-web`).
85
-
* **After Documentation Edits (`.md`):** After I edit any Markdown file (including this one), I will run `make lint-markdown` to check for formatting and style issues.
86
-
87
-
## Tool Usage Principles
88
-
89
-
* **File Editing:** When modifying existing files, especially collaboratively edited files like `GEMINI.md`, do not carelessly overwrite the entire file with `write_file`. First, read the current content with `read_file` to check for user changes, then use the `replace` tool to update only the differences. This prevents unintentional overwrites.
90
-
* **Non-ASCII Character Verification:** When editing files containing non-ASCII characters like Japanese, text corruption may occur. To detect and correct this, the following procedure must be followed:
91
-
1. Immediately after executing `write_file` or `replace`, **always re-read the written content using `read_file`**.
92
-
2. Verify that the re-read content perfectly matches the intended written content.
93
-
3. In the unlikely event that corruption is confirmed, immediately overwrite the file again with the correct content to fix it. Do not proceed to other tasks until this correction is complete. (If `write_file` or `replace` cannot solve the problem, use commands like `sed` to resolve it).
94
-
* **Safe Execution of Multi-line Shell Commands:** To safely pass multi-line strings to shell commands like `git commit`, I will use the `printf` command combined with a pipe (`|`). This method is more robust than using here-documents within the `run_shell_command` tool.
95
-
96
-
When constructing the string for `printf`, I must pay close attention to shell expansions and escape sequences.
97
-
* **Newlines** must be explicitly written as `\n`.
98
-
* **Special characters**: Quotes (`"` and `'`) within the message must be properly escaped with a backslash (`\`) to prevent shell misinterpretation. Do not use backticks (`) in the message.
1
+
# Kubernetes History Inspector (KHI) Developer Guide
99
2
100
-
```bash
101
-
# Example: Using printf with proper escaping
102
-
printf "feat(gemini): add new rule\n\nThis commit's body contains a \"quoted\" word." | git commit -F -
103
-
```
104
-
105
-
* **Handling of Long-Running Commands:** To ensure stable and predictable interactions, my execution of shell commands is guided by the following principles:
106
-
* **Verification with Single-Run Commands:** For verifying my changes, I will prioritize single-run, terminating commands (e.g., `make build`, `make test`, `make lint`). These provide clear success or failure results.
107
-
* **Requesting Long-Running Tasks:** I will **not** directly execute long-running commands that do not terminate on their own (e.g., `make watch-web`, `ng test`). Instead, I will request that you, the user, run these commands in your own terminal. This prevents my CLI from becoming blocked and ensures you have full control over these processes.
108
-
109
-
---
110
-
111
-
# Part 1: Project Overview
3
+
## Part 1: Project Overview
112
4
113
5
## Project Purpose
114
6
115
7
Kubernetes History Inspector (KHI) is a log visualization tool for Kubernetes clusters.
116
-
It visualizes large volumes of logs in interactive timeline views, providing powerful support for troubleshooting complex issues that span multiple components within a Kubernetes cluster.
117
-
118
-
It does not require the installation of agents in the cluster. By simply loading the logs, it provides log visualizations useful for troubleshooting.
8
+
It visualizes large volumes of logs in interactive timeline views, providing powerful support for troubleshooting complex issues that span multiple components within a Kubernetes By simply loading the logs, it provides log visualizations useful for troubleshooting.
119
9
120
10
## Primary Technology Stack
121
11
122
12
***Backend:** Go
123
-
* **Frontend:** Angular, TypeScript
13
+
***Frontend:** Angular 20, TypeScript
124
14
***Build:** Makefile, npm
125
15
***Container:** Docker
126
16
127
17
---
128
18
129
-
# Part 2: Getting Started
19
+
##Part 2: Getting Started
130
20
131
21
## Setup Instructions
132
22
133
23
1.**Install Dependencies:**
134
-
* Go 1.24.*
24
+
* Go 1.25.*
135
25
* Node.js 22.13.*
136
26
*`gcloud` CLI
137
27
*`jq`
@@ -209,7 +99,7 @@ The frontend development server is started with `make watch-web`.
209
99
210
100
---
211
101
212
-
# Part 3: Development Workflow & Conventions
102
+
## Part 3: Development Workflow & Conventions
213
103
214
104
## Coding Conventions
215
105
@@ -234,7 +124,6 @@ Please follow Google's coding conventions as much as possible.
234
124
* Use the **`input()`** signal function for component inputs instead of the `@Input` decorator.
235
125
* Prefer **Signals** over RxJS for component-level state management.
236
126
* In templates, use built-in control flow (**`@for`**, **`@if`**) over structural directives (`*ngFor`, `*ngIf`).
237
-
* TODO: Specify compliance with a style guide (e.g., Angular Style Guide).
0 commit comments