Files
harvester-ui-extension/docs/agents.md
marcelofukumotoandVolker Theile fcc8f27f40 chore: backport shell 3.0.14 and SUSE Virtualization naming to v1.9 (#1215)
* chore(deps): bump @rancher/shell to 3.0.13 (#1130)

Clears 26 of the 54 open Dependabot alerts (axios, dompurify, serve-static, and
drops vulnerable send / @tootallnate/once copies).

3.0.13 ships the flat-config ESLint 10 toolchain, so lint now routes through the
@rancher/shell launcher (keeping the legacy .eslintrc on ESLint 7); a prelint step
installs an ESLint-7-compatible eslint-plugin-jest into the isolated toolchain.

Conflicts resolved: yarn.lock
(yarn.lock regenerated with yarn install; package.json keeps the release branch dependencies)

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>
(cherry picked from commit 00584f1d19)

* feat: Add a unit test target (jest) to the UI extension and run it in CI (#1192)

- Introduce test targets.
- Adding additional tests.

Related to: https://github.com/harvester/harvester/issues/11892

Signed-off-by: Volker Theile <vtheile@suse.com>
(cherry picked from commit 71141b257a)
Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* chore(deps): bump @rancher/shell to 3.0.14 (#1208)

* chore(deps): bump @rancher/shell to 3.0.14

3.0.14 resolves [[name]] tokens in translations from values registered
as l10n globals, which the standalone UI needs to pick the product name.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: save cloud-config template edits with @rancher/shell 3.0.14

The YamlEditor of shell 3.0.14 no longer emits onChanges, so editing a
template saved its old cloud config. Copy the text from update:value,
which both shell versions emit.

Jest transforms @replit/codemirror-vim-core, an ESM-only dependency of
the new YamlEditor, like the dashboard does.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: keep the YAML editor heights with CodeMirror 6

The min-height rules targeted the CodeMirror 5 element, so the editors
shrank to their text.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: reject IP ranges the network settings don't support

The CIDR check of @rancher/shell 3.0.14 also accepts short forms such as
10.1/16, extra parts and IPv6, so the VM migration, RWX and storage
network settings saved them. Use a strict IPv4 CIDR check of our own.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: keep the look of the file selector buttons

The FileSelector of @rancher/shell 3.0.14 no longer takes button classes
and renders a medium secondary button. Pass the variant and size that
match the previous primary and secondary buttons.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: keep Enter in a migration wizard field on the same step

The Wizard of @rancher/shell 3.0.14 renders its step headers as submit
buttons, so Enter in a text field clicked the first one and jumped back
to step 1.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: show the created message after a restore, upgrade or upload

Since @rancher/shell 3.0.14, save() no longer shows the message for
resources with a generated name; callers show it with
notifyGeneratedName().

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* refactor: fold the logging output buffer with the CodeMirror 6 helpers

The YAML editor of @rancher/shell 3.0.14 is CodeMirror 6, and its
CodeMirror 5 methods are deprecated.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: keep the shell's table views off in standalone

@rancher/shell 3.0.14 turns its table views on for every list in the
standalone UI, as the server has no ui-configurable-tables feature and
the default is on. The table views drop the filters the lists put in the
table header, which also left the Images list empty. Add the feature,
disabled, to the management store in standalone only.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: reject zero-padded octets in IP ranges

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

---------

Conflicts resolved: package.json, yarn.lock
(yarn.lock regenerated with yarn install; package.json keeps the release branch dependencies)

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>
(cherry picked from commit d6f6f7c54c)

* feat: use the SUSE Virtualization product name on Prime (#1202)

* feat: switch the product name with Rancher Prime

Use a [[Harvester]] token for the product name in the translations, so
Rancher 2.16 fills it from the l10n global that harvester-manager
registers: SUSE Virtualization on Rancher Prime, Harvester otherwise.

Rancher before 2.16 shows the tokens as written, so on those hosts (and
standalone) the extension resolves them to Harvester itself.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* feat: switch the standalone product name with the server flavor

Standalone has no Rancher Prime, so register the [[Harvester]] l10n
global from the server-flavor setting instead: SUSE Virtualization on
prime, Harvester otherwise.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: point the network policy banner to the documentation

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* feat: use the SUSE theme in standalone Prime

Standalone Prime kept the harvester brand and only overrode the primary
colour, so the rest of the palette and the fonts didn't match Rancher
Prime. Switch the ui-brand setting to suse in the store when the server
flavor is prime, which makes the shell load the SUSE theme.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

* fix: keep the SUSE theme after a brand setting change event

The watcher also reads the setting's value, so a change from the server
loaded into the same object switches the brand back to suse.

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>

---------

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>
(cherry picked from commit 6e0e0237ef)

---------

Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com>
Signed-off-by: Volker Theile <vtheile@suse.com>
Co-authored-by: Volker Theile <vtheile@suse.com>
2026-11-04 18:05:58 +08:00
..

# Agents.md

This folder contains files used to construct a single root `AGENTS.md`

We do this because
- The single commonality between almost all AI tools is that they look for a root `AGENTS.md`
- Having the information in a single place for all AI tools is better than duplicating and maintaining the information in multiple files for each AI tool

## Process
1. Add files to or update files in `./docs/agents.md/agents`, `./docs/agents.md/personas`, `./docs/agents.md/contributors`.
2. Each file must
  - Start markdown headers at the `##` level
  - End in a new line
  - Order contents in AGENTS.md by giving an optional number prefix
3. Run `yarn agents:generate`.
   - Take the contents of `./docs/agents.md/template_agents.md`
   - Insert the contents of the agents, personas and contributors files
   - Output to `./AGENTS.md`
4. Commit all changes, including root `./AGENTS.md` and any files that link to it

## Guidance

### Examples

When referencing code or configuration it's good to include an example

## Future Tasks
- Add real world examples when referencing code
- Create a GH workflow to monitor `agents.md` folder files in a PR, if changed run generate script and add new AGENTS.md to PR
- Discuss
  - Three multi AI tool related questions
    - Questions
      - how AI specific patterns, like co-pilot instructions, can be expressed in a way to be adopted by or reduce duplication with the root agents.md
      - how AI tool specific metadata code can be included
      - multiple agents vs personas approach works
    - Proposal
      - Generic information applicable to all AI tools is added to the root `agents.md`
      - Agent, instruction or other AI specific files or patterns can be used in files specific to that AI tool. They must not contain duplicate information to the root `agents.md`
      - The root `agents.md` continues to be AI tool agnostic
  - How can folder specific agents be used
    - Proposal
      - `agents.md` are added to folders as long as most LLMs can make use of them and they do not duplicate information in the root `agents.md`

## Test Prompts

To validate LLMs are picking up information consider running the following prompts.

### Information

Can they provide correct information?

- `what's this project about?`
- `can you tell me the process for fixing a github issue in this repo?`
- `what makes a good software developer?`
- `what should never be done in this project?`
- `what are the folders in this project for?`
- `what are the env vars i could use when running e2e tests?`

### Actions

Can they use the information in their actions?

Pending