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
{{ message }}
Repository navigation
Commit 7bf59e1
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: AGENTS.md
+17-15Lines changed: 17 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,9 +4,12 @@ These instructions apply to the entire repository. More-specific `AGENTS.md` fil
4
4
5
5
## Working Practices
6
6
7
-
- Inspect the relevant implementation, tests, benchmarks, project files, and nearby code before proposing or making changes. Do not infer current behavior when the source is available.
7
+
- Inspect only the source and supporting files needed for the task before proposing or making changes. Do not infer current behavior when the source is available.
8
8
- Make the smallest complete change that solves the requested problem. Avoid unrelated cleanup, speculative abstractions, and formatting churn.
9
-
- Match established architecture, naming, formatting, documentation, and test patterns. Treat `.editorconfig`, analyzers, and repository build settings as authoritative.
9
+
- Trace the existing execution path before changing it. Extend and optimize the existing implementation within the requested behavior and affected path.
10
+
- Before implementing an operation, find and inspect the existing APIs that provide it. Use or extend those APIs instead of writing equivalent logic elsewhere. This includes color conversion, pixel conversion, memory management, and vectorized operations. If an API lacks required behavior, improve its owning implementation rather than bypassing it with a separate implementation.
11
+
- Follow existing naming, formatting, documentation, and test patterns. Treat `.editorconfig`, analyzers, and repository build settings as authoritative.
12
+
- Use simple technical English in all communication, documentation, and comments. Use short sentences, active voice, and existing code terminology.
10
13
- Preserve public API and observable behavior unless the task explicitly requires a change. Public API documentation must describe observable behavior, not implementation details.
11
14
- Do not use reflection against built assemblies, ad hoc assembly loading, or temporary probe projects unless explicitly requested.
@@ -15,27 +18,26 @@ These instructions apply to the entire repository. More-specific `AGENTS.md` fil
15
18
16
19
- Treat throughput, latency, memory use, and binary size as design constraints, especially in pixel-processing, drawing, parsing, encoding, and other hot paths.
17
20
- Avoid unnecessary allocations, copies, boxing, closures, interface dispatch, repeated enumeration, and extra passes over data.
18
-
- Reuse the repository's existing memory ownership, pooling, span, vectorization, and parallelization patterns. Do not introduce a new mechanism when an established one fits.
19
-
-Keep hot loops simple and bounds-check-friendly. Hoist invariant work, preserve locality, and use the narrowest suitable data types without sacrificing correctness.
20
-
-Do not trade correctness or maintainability for assumed speed. Support non-obvious optimizations with measurements or clear evidence, and add or update benchmarks when performance is the purpose of the change.
-Use a SIMD-first design for suitable data processing code. Build on existing vectorized operations, dispatch mechanisms, and scalar fallbacks. Keep hot loops simple, hoist invariant work, and preserve memory locality.
23
+
-Preserve correctness and maintainability during optimization. Distinguish source-based reasoning from measured results. Claim a speedup only with measurements. Use existing benchmarks first. Add or update cases only when they measure relevant behavior that existing benchmarks miss.
21
24
- Consider all supported target frameworks and runtime capabilities. Do not regress fallback paths while optimizing newer runtimes.
22
25
23
26
## C# Conventions
24
27
25
-
- Follow the existing code around the change; local patterns take precedence over generic preferences.
28
+
- Follow local patterns when they comply with the explicit rules.
26
29
- Do not use `record` or `record struct` types.
27
30
- Prefer established invariants over redundant guards. Validate at real external boundaries and do not add defensive checks for internally controlled states.
28
-
- Do not extract single-use helpers merely to name a block. Extract only for genuine reuse, an established local pattern, or meaningful complexity reduction.
31
+
- Do not extract single-use helpers merely to name a block. Extract only for genuine reuse, an established local pattern, or independently complex logic.
29
32
- Add vertical whitespace after multi-line statements and declarations and between distinct logical stages. Never add trailing whitespace.
30
-
- Document every method, constructor, and property, regardless of whether it is public, internal, protected, or private. Keep public API documentation limited to observable behavior; use private and internal documentation to capture the contract and intent needed to maintain the code.
31
-
- Add inline comments throughout complex code. Explain algorithms, formulas, invariants, ownership, compatibility behavior, and performance tradeoffs at the operations and decisions they govern. Explain why the code is shaped that way rather than narrating the syntax.
32
-
- Document SIMD code especially thoroughly. Explain the vector layout, lane meaning, widening or narrowing, masks, shuffles, constants, alignment or remainder handling, supported instruction paths, scalar equivalence, and the reason each non-obvious operation is correct.
33
-
- Write algorithm and SIMD comments for a maintainer who is unfamiliar with the implementation. The reader should not need to reconstruct intent from external documentation, issue history, or benchmark results.
33
+
- Document every added method, constructor, and property, regardless of visibility. Update documentation when a member's behavior or contract changes. Keep public API documentation limited to observable behavior. Use private and internal documentation to explain the contract and intent.
34
+
- Add inline comments that explain why complex code works. Explain algorithms, formulas, invariants, memory ownership, compatibility behavior, and performance decisions where they apply.
35
+
- For SIMD, explain lane layouts, operations, alignment, remainders, and scalar equivalence so an unfamiliar maintainer can follow the code.
34
36
35
37
## Verification
36
38
37
-
- Add or update focused tests when behavior changes, following the test framework and conventions already used by the project.
38
-
- Never hack, weaken, skip, conditionally bypass, or otherwise manipulate a test to make it pass. Fix the production defect or the genuine test defect while preserving the test's intended coverage and sensitivity.
39
-
- Do not update golden files, reference images, snapshots, baselines, or expected-output artifacts to resolve a test failure. Treat a mismatch as evidence to investigate and correct the implementation.
40
-
-Run the narrowest relevant formatting, test, and Release build commands, then expand verification in proportion to the risk and scope of the change.
39
+
- Add or update tests only when they prove a required behavior or expose a real defect. Derive expectations from established contracts, explicit requirements, or defect evidence. Use source to identify contracts and integration points, not to copy implementation results into expectations. Prefer extending existing tests. Avoid redundant cases and assertions that merely repeat the implementation.
40
+
- Never weaken, skip, or bypass a valid test to make it pass. Fix the production defect or the genuine test defect. Replace or remove a test only with evidence that its expectation is invalid or its coverage is redundant.
41
+
- Do not update golden files, reference images, snapshots, baselines, or expected-output artifacts merely to silence a failure. Investigate mismatches. Update expected results only for an established requirement change or an incorrect reference result proved by independent contract or defect evidence.
42
+
-Test the actual behavior through the existing execution path. Synthetic inputs must exercise an established requirement or reproduce a real defect. Do not invent requirements or substitute internal structure and helper calls for assertions about required behavior. Run the narrowest relevant formatting, test, and Release build commands.
41
43
- Report what changed, the verification performed, and any remaining risks or unverified assumptions.
Copy file name to clipboardExpand all lines: README.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -89,6 +89,17 @@ There are three tools contained within the submodule that will help to automatic
89
89
The build also copies repository-wide AI coding guidance for tools that support `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, and `.github/copilot-instructions.md`.
90
90
91
91
These tools are automatically installed into your solution by referencing the `.props` and `.targets` files found in the [/msbuild](/msbuild) folder.
92
+
93
+
### .NET SDK Resolution (global.json)
94
+
95
+
The repository root contains a [global.json](/global.json) that controls .NET SDK resolution for all SixLabors repositories:
96
+
97
+
-`version` and `rollForward: latestMajor` set a floor of .NET 10. Resolution selects the newest installed SDK at or above that floor.
98
+
-`allowPrerelease: true` lets the CLI and Visual Studio use a preview SDK when one is installed. Machines without a preview SDK resolve the newest stable release.
99
+
100
+
The build copies this file to consuming repositories together with the other shared config files. Commit the copied file, as you do with `.editorconfig` and `.gitattributes`.
101
+
102
+
Preview target frameworks are opt-in. Set the `SIXLABORS_TESTING_PREVIEW` environment variable to `True` to add them to `TargetFrameworks`. CI preview lanes set this variable and install the preview SDK with the `dotnet-quality: preview` option of `setup-dotnet`.
Six Labors provides security updates for the latest major version of each library.
6
+
7
+
Each major version remains eligible for security updates for 12 months after the first stable release of the next major version of that library.
8
+
After this period, that major version is end-of-life and does not receive security updates.
9
+
10
+
Users must install the latest available patch or minor release within a supported major version to receive security fixes.
11
+
Older releases within that major version are not maintained separately.
12
+
13
+
| Version | Supported |
14
+
| ------- | --------- |
15
+
| Latest major version | Yes |
16
+
| Superseded major version within 12 months of the next major's first stable release | Yes |
17
+
| Superseded major version after that 12-month period | No |
18
+
19
+
Security updates may require a license key under the existing license terms. This does not change the license terms.
20
+
21
+
This policy covers security fixes only. It does not include feature backports or extend support for underlying .NET versions.
22
+
23
+
Security fixes, if any, are provided at Six Labors' discretion.
24
+
25
+
This policy does not create any obligation to provide support, maintenance services, SLAs, custom fixes, hosted services, managed services, operational monitoring, professional services, consulting, or certification of customer products.
26
+
27
+
## Reporting a Vulnerability
28
+
29
+
Please report suspected security vulnerabilities using GitHub private vulnerability reporting for the relevant Six Labors repository, where available.
30
+
31
+
If GitHub private vulnerability reporting is not available for a repository, please report suspected security vulnerabilities by contacting Six Labors through the contact details published on the Six Labors website.
32
+
33
+
Do not report security vulnerabilities through public GitHub issues.
34
+
35
+
When reporting a vulnerability, please include as much relevant information as possible:
36
+
37
+
* affected package and version
38
+
* target framework and runtime
39
+
* operating system
40
+
* input file or minimal reproduction, if safe to share
41
+
* expected and actual behavior
42
+
* potential security impact
43
+
* whether you believe the issue is being actively exploited
44
+
45
+
Six Labors may review reported vulnerabilities and determine whether they are security issues affecting a supported version.
46
+
47
+
A report may be declined or closed without action if, in Six Labors' opinion, it:
48
+
49
+
* is not reproducible
50
+
* does not affect a supported version
51
+
* affects only an unsupported or end-of-life version
52
+
* is not a security vulnerability
53
+
* depends on unsafe, unsupported, or unintended use
54
+
* depends on a vulnerable application, environment, dependency, configuration, or deployment outside the Six Labors library itself
55
+
* lacks sufficient information for assessment
56
+
* is duplicative
57
+
* has already been fixed
58
+
* is otherwise outside the scope of this policy
59
+
60
+
If a vulnerability is accepted, Six Labors may handle it through GitHub Security Advisories and, where appropriate, CVE assignment.
61
+
62
+
Six Labors does not guarantee any response time, fix time, release date, advisory publication date, CVE assignment, workaround, mitigation, or particular outcome for any report.
63
+
64
+
## Scope
65
+
66
+
This policy applies only to security vulnerabilities in Six Labors libraries themselves.
67
+
68
+
This policy does not apply to:
69
+
70
+
* customer applications
71
+
* customer products
72
+
* customer deployments
73
+
* customer infrastructure
74
+
* customer data
75
+
* third-party services
76
+
* unsupported versions
77
+
* end-of-life versions
78
+
* forks or modified versions
79
+
* usage outside the documented or intended behavior of the relevant library
80
+
81
+
Organizations using Six Labors libraries are responsible for assessing, securing, testing, monitoring, updating, and maintaining their own applications, products, deployments, infrastructure, and supply chains.
82
+
83
+
## Cyber Resilience Act
84
+
85
+
Six Labors libraries are general-purpose software libraries.
86
+
87
+
They are not cybersecurity products, identity or access management systems, password managers, operating systems, browsers, firewalls, network management tools, SIEM tools, hypervisors, container runtimes, or other Cyber Resilience Act important or critical product classes.
88
+
89
+
If a Six Labors library is treated as a product with digital elements under the Cyber Resilience Act, Six Labors assesses it as an ordinary software component.
90
+
91
+
Organizations incorporating Six Labors libraries into products made available on the EU market are responsible for assessing and meeting their own regulatory obligations for those products, including any obligations under the Cyber Resilience Act.
92
+
93
+
Six Labors does not provide support, maintenance services, SLAs, managed services, hosted services, operational monitoring, custom fixes, professional services, consulting, or certification of customer products.
94
+
95
+
Security vulnerabilities in supported Six Labors libraries are handled through the GitHub Security Advisory process for the relevant repository, where appropriate.
96
+
97
+
From 11 September 2026, if Six Labors becomes aware of credible active exploitation of a vulnerability in a supported Six Labors library, or a severe security incident affecting a supported Six Labors library, Six Labors may report the matter through the applicable Cyber Resilience Act reporting mechanism where legally required.
98
+
99
+
## No Warranty
100
+
101
+
Six Labors libraries are provided in accordance with their applicable license terms.
102
+
103
+
Nothing in this policy creates any warranty, representation, guarantee, support obligation, maintenance obligation, service commitment, regulatory certification, or assumption of responsibility for any customer product, customer deployment, customer compliance obligation, or third-party system.
0 commit comments