From efec6add619664957c5de9b40e41fd69cb93ce61 Mon Sep 17 00:00:00 2001 From: alexion Date: Sat, 29 Aug 2026 22:47:50 -0400 Subject: [PATCH] chore(repo): initialize workspace --- .gitignore | 27 +++++++ AGENTS.md | 12 +++ docs/conventional-commits.md | 141 +++++++++++++++++++++++++++++++++++ flake.lock | 27 +++++++ flake.nix | 26 +++++++ src/.envrc | 1 + 6 files changed, 234 insertions(+) create mode 100644 .gitignore create mode 100644 AGENTS.md create mode 100644 docs/conventional-commits.md create mode 100644 flake.lock create mode 100644 flake.nix create mode 100644 src/.envrc diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..a43f8a0 --- /dev/null +++ b/.gitignore @@ -0,0 +1,27 @@ +# direnv local state +.direnv/ + +# local environment overrides +.env +.env.* +!.env.example +!.envrc + +# editor and OS noise +.DS_Store +Thumbs.db +*~ +*.swp +*.swo + +# logs +*.log + +# language package-manager caches and outputs +node_modules/ +dist/ +build/ +target/ +.result +result +result-* diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..e3f8874 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,12 @@ +# Repository instructions + +## Commit convention + +Use Conventional Commits for all commit messages. +Before writing a commit message, please read [[docs/conventional-commits]]. +Do not add agent attribution or co-author trailers. + +## Gotchas + +- When materializing an external specification, standard, or project-maintained convention, use the upstream source instead of reconstructing it from memory. + Preserve local policy separately from copied upstream text. diff --git a/docs/conventional-commits.md b/docs/conventional-commits.md new file mode 100644 index 0000000..6bec3a5 --- /dev/null +++ b/docs/conventional-commits.md @@ -0,0 +1,141 @@ +# Conventional Commits 1.0.0 + +## Summary + +The Conventional Commits specification is a lightweight convention on top of commit messages. +It provides an easy set of rules for creating an explicit commit history; +which makes it easier to write automated tools on top of. +This convention dovetails with [SemVer](http://semver.org), +by describing the features, fixes, and breaking changes made in commit messages. + +The commit message should be structured as follows: + +--- + +``` +[optional scope]: + +[optional body] + +[optional footer(s)] +``` + +--- + +The commit contains the following structural elements, to communicate intent to the +consumers of your library: + +1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in Semantic Versioning). +2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in Semantic Versioning). +3. **BREAKING CHANGE:** a commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in Semantic Versioning). +A BREAKING CHANGE can be part of commits of any _type_. +4. _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type)) recommends `build:`, `chore:`, + `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. +5. _footers_ other than `BREAKING CHANGE: ` may be provided and follow a convention similar to + [git trailer format](https://git-scm.com/docs/git-interpret-trailers). + +Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). +A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`. + +## Examples + +### Commit message with description and breaking change footer + +``` +feat: allow provided config object to extend other configs + +BREAKING CHANGE: `extends` key in config file is now used for extending other config files +``` + +### Commit message with `!` to draw attention to breaking change + +``` +feat!: send an email to the customer when a product is shipped +``` + +### Commit message with scope and `!` to draw attention to breaking change + +``` +feat(api)!: send an email to the customer when a product is shipped +``` + +### Commit message with both `!` and BREAKING CHANGE footer + +``` +chore!: drop support for Node 6 + +BREAKING CHANGE: use JavaScript features not available in Node 6. +``` + +### Commit message with no body + +``` +docs: correct spelling of CHANGELOG +``` + +### Commit message with scope + +``` +feat(lang): add Polish language +``` + +### Commit message with multi-paragraph body and multiple footers + +``` +fix: prevent racing of requests + +Introduce a request id and a reference to latest request. Dismiss +incoming responses other than from latest request. + +Remove timeouts which were used to mitigate the racing issue but are +obsolete now. + +Reviewed-by: Z +Refs: #123 +``` + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., + followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space. +2. The type `feat` MUST be used when a commit adds a new feature to your application or library. +3. The type `fix` MUST be used when a commit represents a bug fix for your application. +4. A scope MAY be provided after a type. +A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):` +5. A description MUST immediately follow the colon and space after the type/scope prefix. +The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_. +6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. +The body MUST begin one blank line after the description. +7. A commit body is free-form and MAY consist of any number of newline separated paragraphs. +8. One or more footers MAY be provided one blank line after the body. +Each footer MUST consist of a word token, followed by either a `:` or `#` separator, followed by a string value (this is inspired by the [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)). +9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). +An exception is made for `BREAKING CHANGE`, which MAY also be used as a token. +10. A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed. +11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer. +12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., _BREAKING CHANGE: environment variables now take precedence over config files_. +13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. +If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change. +14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: updated ref docs._ +15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase. +16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer. + +## FAQ + +### How does Conventional Commits handle revert commits? + +Reverting code can be complicated: are you reverting multiple commits? +if you are reverting a feature, should the next release instead be a patch? + +Conventional Commits does not make an explicit effort to define revert behavior. +Instead we leave it to tooling authors to use the flexibility of _types_ and _footers_ to develop their logic for handling reverts. + +One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted: + +``` +revert: let us never again speak of the noodle incident + +Refs: 676104e, a215868 +``` diff --git a/flake.lock b/flake.lock new file mode 100644 index 0000000..6020ba5 --- /dev/null +++ b/flake.lock @@ -0,0 +1,27 @@ +{ + "nodes": { + "nixpkgs": { + "locked": { + "lastModified": 1787736819, + "narHash": "sha256-cV5xEJJK3BvhU8rEd4mC9UsmDi5qscv/kzGPhBRC5WA=", + "owner": "nixos", + "repo": "nixpkgs", + "rev": "9fbb54b33e91ee4ca368e35a78e0613c720600b3", + "type": "github" + }, + "original": { + "owner": "nixos", + "ref": "nixos-unstable", + "repo": "nixpkgs", + "type": "github" + } + }, + "root": { + "inputs": { + "nixpkgs": "nixpkgs" + } + } + }, + "root": "root", + "version": 7 +} diff --git a/flake.nix b/flake.nix new file mode 100644 index 0000000..c27f358 --- /dev/null +++ b/flake.nix @@ -0,0 +1,26 @@ +{ + description = "alexion.dev"; + + inputs = { + # Base nixpkgs channel. + nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable"; + }; + + outputs = { nixpkgs, ... }: + let + system = "x86_64-linux"; + pkgs = import nixpkgs { + inherit system; + config.allowUnfree = true; + }; + in + { + devShells.${system} = { + test = pkgs.mkShell { + shellHook = '' + echo "Hello world!" + ''; + }; + }; + }; +} diff --git a/src/.envrc b/src/.envrc new file mode 100644 index 0000000..bda8798 --- /dev/null +++ b/src/.envrc @@ -0,0 +1 @@ +use flake //#test