Skip to content

Commit f8f3347

Browse files
KSemenenkoKSemenenko
committed
Fix FeatureChecker agent commands
Add FeatureChecker platform and access layer clean Add LaunchDarkly-inspired feature SDK Reorganize FeatureChecker into vertical slices Migrate solution to slnx Update README and repository metadata bump version clean clena
1 parent 4d4b00a commit f8f3347

257 files changed

Lines changed: 25633 additions & 392 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.codex/skills/analyzer-config/SKILL.md‎

Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
---
2+
name: analyzer-config
3+
description: "Use a repo-root `.editorconfig` to configure free .NET analyzer and style rules. Use when a .NET repo needs rule severity, code-style options, section layout, or analyzer ownership made explicit. USE FOR: the repo needs a root .editorconfig; analyzer severity and style ownership are unclear; the team wants one source of truth for rule configuration. DO NOT USE FOR: choosing analyzers with no config change; formatting-only execution with no config ownership question. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
4+
compatibility: "Requires a .NET SDK-based repository; respects the repo's `AGENTS.md` commands first."
5+
---
6+
7+
# .NET Analyzer Configuration
8+
9+
## Trigger On
10+
11+
- the repo needs a root `.editorconfig`
12+
- analyzer severity and style ownership are unclear
13+
- the team wants one source of truth for rule configuration
14+
15+
## Value
16+
17+
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
18+
- reduce ambiguity through explicit planning, verification, and final validation skills
19+
- leave reusable project context so future tasks are faster and safer
20+
21+
## Do Not Use For
22+
23+
- choosing analyzers with no config change
24+
- formatting-only execution with no config ownership question
25+
26+
## Inputs
27+
28+
- the nearest `AGENTS.md`
29+
- current `.editorconfig`
30+
- any `Directory.Build.props` overrides
31+
32+
## Quick Start
33+
34+
1. Read the nearest `AGENTS.md` and confirm scope and constraints.
35+
2. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.
36+
3. Return the `Required Result Format` with concrete artifacts and verification evidence.
37+
38+
## Workflow
39+
40+
1. Prefer one repo-root `.editorconfig` with `root = true`.
41+
2. Add nested `.editorconfig` files when a subtree has a clear scoped purpose, such as stricter rules, different generated-code handling, or a different policy for tests or legacy code.
42+
3. Keep severity in `.editorconfig`, not scattered through IDE settings.
43+
4. Write the file as real EditorConfig, not as a made-up `.NET` variant:
44+
- lowercase filename `.editorconfig`
45+
- `root = true` in the preamble
46+
- no inline comments
47+
- forward slashes in globs
48+
5. Keep bulk switches such as `EnableNETAnalyzers` in MSBuild files, not in `.editorconfig`.
49+
6. Treat `.globalconfig` as an exceptional case, not the normal repo setup.
50+
51+
## Bootstrap When Missing
52+
53+
If analyzer configuration is requested but not structured yet:
54+
55+
1. Detect current state:
56+
- `rg --files -g '.editorconfig' -g '.globalconfig'`
57+
- `rg -n "EnableNETAnalyzers|AnalysisLevel|AnalysisMode" -g '*.csproj' -g 'Directory.Build.*' .`
58+
2. Create or normalize one repo-root `.editorconfig` with `root = true`.
59+
3. Move rule severity into `.editorconfig` and keep bulk analyzer switches in project or MSBuild config.
60+
4. Add nested `.editorconfig` files only when a subtree really needs different scoped policy.
61+
5. Run `dotnet build SOLUTION_OR_PROJECT` and return `status: configured` or `status: improved`.
62+
6. If the repo intentionally uses another documented analyzer-config ownership model, return `status: not_applicable`.
63+
64+
## Deliver
65+
66+
- one explicit analyzer configuration ownership model
67+
- a root `.editorconfig` layout that agents can extend safely
68+
69+
## Validate
70+
71+
- rule severity is reproducible in local and CI builds
72+
- IDE-only settings do not silently override repo policy
73+
- the default path is a root `.editorconfig`, not a surprise alternative
74+
75+
## Ralph Loop
76+
77+
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
78+
79+
1. Plan first (mandatory):
80+
- analyze current state
81+
- define target outcome, constraints, and risks
82+
- write a detailed execution plan
83+
- list final validation skills to run at the end, with order and reason
84+
2. Execute one planned step and produce a concrete delta.
85+
3. Review the result and capture findings with actionable next fixes.
86+
4. Apply fixes in small batches and rerun the relevant checks or review steps.
87+
5. Update the plan after each iteration.
88+
6. Repeat until outcomes are acceptable or only explicit exceptions remain.
89+
7. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.
90+
91+
### Required Result Format
92+
93+
- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`
94+
- `plan`: concise plan and current iteration step
95+
- `actions_taken`: concrete changes made
96+
- `validation_skills`: final skills run, or skipped with reasons
97+
- `verification`: commands, checks, or review evidence summary
98+
- `remaining`: top unresolved items or `none`
99+
100+
For setup-only requests with no execution, return `status: configured` and exact next commands.
101+
102+
## Load References
103+
104+
- [references/analyzer-config.md](references/analyzer-config.md)
105+
- [references/template.md](references/template.md)
106+
- [references/rules.md](references/rules.md)
107+
108+
## Example Requests
109+
110+
- "Make `.editorconfig` the source of truth."
111+
- "Write a proper root `.editorconfig` for this repo."
112+
- "Fix conflicting analyzer severities in this .NET repo."

‎.codex/skills/analyzer-config/manifest.json‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
{
2+
"version": "1.0.0",
3+
"category": "Code Quality"
4+
}

‎.codex/skills/analyzer-config/references/analyzer-config.md‎

Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
# .NET Root .editorconfig
2+
3+
## Open/Free Status
4+
5+
- built-in .NET configuration system
6+
- free to use
7+
8+
## Default Placement
9+
10+
The default MCAF path is:
11+
12+
- one repo-root lowercase `.editorconfig`
13+
- `root = true` at the top
14+
- optional nested `.editorconfig` files when a subtree has a clear scoped purpose
15+
16+
## Verify First
17+
18+
Before adding a new config file, check whether the repo already has one:
19+
20+
```bash
21+
rg --files -g '.editorconfig' -g '.globalconfig'
22+
```
23+
24+
## File Format
25+
26+
`EditorConfig` is an INI-style format:
27+
28+
- section names are path globs like `[*.cs]` or `[src/**/*.cs]`
29+
- files are read from the current file directory upward
30+
- `root = true` stops the search
31+
- closer matching `.editorconfig` files override earlier parent rules
32+
- later matching sections in the same file win
33+
- comments must be on their own line and start with `#` or `;`
34+
- inline comments are not part of the format
35+
- the file should be UTF-8 with `LF` or `CRLF` line separators
36+
- forward slashes are the path separator in section globs
37+
- keys and values are case-insensitive
38+
- `unset` removes the effect of a previously set property
39+
40+
## Core Rules That Matter for .NET
41+
42+
- only `root` belongs in the preamble for effect outside sections
43+
- all other effective pairs belong under a matching section such as `[*.cs]`
44+
- unknown keys are allowed by the EditorConfig format, which is why `.NET`-specific keys like `dotnet_diagnostic.*`, `dotnet_style_*`, and `csharp_*` can live in `.editorconfig`
45+
- unsupported keys or values may be ignored by a given plugin or tool, so keep repo expectations tied to tools that actually honor them
46+
47+
## Glob Rules That People Commonly Get Wrong
48+
49+
- `*.cs` can match at any level below the directory that contains the `.editorconfig`
50+
- `src/*.cs` is relative to the directory that contains that `.editorconfig`
51+
- if a glob contains `/`, use `/`, never `\\`
52+
- a section ending with `/` does not match a file
53+
- a leading `/` does not add extra meaning if the glob already contains a `/`
54+
55+
## Comments
56+
57+
Good:
58+
59+
```ini
60+
# C# rules
61+
[*.cs]
62+
dotnet_diagnostic.CA1502.severity = warning
63+
```
64+
65+
Bad:
66+
67+
```ini
68+
[*.cs]
69+
dotnet_diagnostic.CA1502.severity = warning # inline comment
70+
```
71+
72+
In the bad example, the trailing `# inline comment` is not a comment under the current specification.
73+
74+
## Recommended Root Layout
75+
76+
Start with one root file like this:
77+
78+
```ini
79+
root = true
80+
81+
[*]
82+
charset = utf-8
83+
end_of_line = lf
84+
insert_final_newline = true
85+
trim_trailing_whitespace = true
86+
87+
[*.cs]
88+
indent_style = space
89+
indent_size = 4
90+
dotnet_analyzer_diagnostic.severity = warning
91+
dotnet_style_qualification_for_method = false:suggestion
92+
dotnet_style_qualification_for_property = false:suggestion
93+
dotnet_style_qualification_for_field = false:suggestion
94+
dotnet_style_qualification_for_event = false:suggestion
95+
96+
[*.{csproj,props,targets}]
97+
indent_style = space
98+
indent_size = 2
99+
```
100+
101+
Then add rule-specific severity in the same root file:
102+
103+
```ini
104+
root = true
105+
106+
[*.cs]
107+
dotnet_diagnostic.CA1000.severity = warning
108+
dotnet_diagnostic.CA1502.severity = warning
109+
dotnet_diagnostic.SA1200.severity = warning
110+
dotnet_diagnostic.RCS1036.severity = error
111+
```
112+
113+
## Scoped Nested .editorconfig
114+
115+
Add a nested `.editorconfig` when a subtree has a real local purpose, for example:
116+
117+
- tighter rules in a core domain
118+
- relaxed rules for generated code
119+
- different test-project conventions
120+
- legacy-code containment during gradual cleanup
121+
122+
Example:
123+
124+
```ini
125+
# src/LegacyModule/.editorconfig
126+
[*.cs]
127+
dotnet_diagnostic.CA1502.severity = error
128+
```
129+
130+
## CI Fit
131+
132+
- `dotnet format` and .NET analyzers both read `.editorconfig`
133+
- repo-root `.editorconfig` should be versioned and treated as the default source of truth
134+
- keep MSBuild switches such as `EnableNETAnalyzers` and `AnalysisLevel` in project files or `Directory.Build.props`
135+
- keep the file lowercase as `.editorconfig`
136+
137+
## Exceptional Use of .globalconfig
138+
139+
Use `.globalconfig` only when you have a real reason, for example:
140+
141+
- analyzer config distributed by package or SDK conventions
142+
- special project layouts where file-tree inheritance is not the right model
143+
144+
That is not the default MCAF recommendation for normal .NET repos.
145+
146+
## When Not To Use
147+
148+
- when the repo is trying to store analyzer policy only in IDE profiles or ephemeral local settings
149+
150+
## Sources
151+
152+
- [EditorConfig home and file location rules](https://editorconfig.org/)
153+
- [EditorConfig formal specification](https://spec.editorconfig.org/)
154+
- [Configuration files for code analysis rules](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files)
155+
- [Code style rule options](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/code-style-rule-options)

0 commit comments

Comments
 (0)