sequra-style 0.2.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 3a9e77fe531700597d097449dc31a2f016903a6e37e4db8b18be3158a4c4abfe
+  data.tar.gz: 7221a139f54b44f292c6c73cb0fbceca30fe1ee4d673af922c49b8e66c605236
+SHA512:
+  metadata.gz: '0675827621a8fe844ef6bc3a418eddce89505e6b7cfc1aae9780400aba222e87f437f64b3ac6ceb0f738a38dc5c4b5c473c8de73032b47a0e7aa6582cd0ce687'
+  data.tar.gz: c71a87b1f3f75a412cb600c6f5edaf7609164fc5ff0720216c30a850ab4c15bf8de47d78d799e24e831c614ef4b6d327482152f75ae92ffd5ba6d612a0934258

data/.github/CODEOWNERS

@@ -0,0 +1 @@
+* @sequra/developer-experience

data/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,46 @@
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+✂✂✂  REMOVE FROM THIS PART BEFORE SUBMITTING YOUR PULL REQUEST ✂✂✂
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+
+Here are some friendly reminders before submitting your pull request:
+
+- There should be a goal describing the motivation for this change.
+- Consider if this change is restricting current style or expanding it.
+- Changes should be discussed with the team before being accepted.
+- Restricting changes should have [severity level `info`](https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Severity) to allow time for adoption before making them mandatory.
+
+YOU CAN REMOVE THE PARTS OF THE TEMPLATE THAT DO NOT APPLY TO YOUR PULL REQUEST
+
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+✂✂✂  REMOVE UP TO THIS PART BEFORE SUBMITTING YOUR PULL REQUEST ✂✂✂
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+
+### What is the goal?
+
+_Provide a description of the overall goal._
+
+### Is this a restricting or expanding change?
+
+**_[RESTRICTING|EXPANDING] change**
+
+_Restricting changes are those that limit the current style or add new rules, while expanding changes are those that remove rules or relax the current ones._
+
+_Changes should be discussed with the team before being accepted._
+
+_Restricting changes should have [severity level `info`](https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Severity) to allow time for adoption before making them mandatory._
+
+### References
+* **Related pull-requests:** _list of related pull-requests (comma-separated): #1, #2_
+* **Any other references:** _list of links to other references (comma-separated): link1, link2_
+
+### How is it being implemented?
+
+_Provide a description of the implementation_
+
+### Opportunistic refactorings
+
+_Have you improved the code/app in anyway? Explain what you did._
+
+### Caveats
+
+_If you find any, please describe all the special conditions._

data/.github/workflows/pr_title_validation.yml

@@ -0,0 +1,20 @@
+name: "Lint PR"
+
+on:
+  pull_request_target:
+    types:
+      - opened
+      - edited
+      - synchronize
+
+permissions:
+  pull-requests: read
+
+jobs:
+  main:
+    name: Validate PR title
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

data/.github/workflows/release.yml

@@ -0,0 +1,33 @@
+name: Create gem release pull request
+on:
+  push:
+    branches:
+      - 'master'
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: GoogleCloudPlatform/release-please-action@v3
+        id: release
+        with:
+          release-type: ruby
+          package-name: sequra-style
+          bump-minor-pre-major: true
+          version-file: 'lib/sequra/sequra-style/version.rb'
+      - uses: actions/checkout@v2
+        if: ${{ steps.release.outputs.release_created }}
+      - uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: 3.2
+        if: ${{ steps.release.outputs.release_created }}
+      - name: Publish gem to Rubygems
+        run: |
+          mkdir -p $HOME/.gem
+          touch $HOME/.gem/credentials
+          chmod 0600 $HOME/.gem/credentials
+          printf -- "---\n:rubygems: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
+          gem build *.gemspec
+          gem push --KEY rubygems --host https://rubygems.org *.gem
+        env:
+          GEM_HOST_API_KEY: "${{ secrets.RUBYGEMS_PUBLISH_TOKEN }}"
+        if: ${{ steps.release.outputs.release_created }}

data/.gitignore

@@ -0,0 +1,8 @@
+/.bundle/
+/.yardoc
+/_yardoc/
+/coverage/
+/doc/
+/pkg/
+/spec/reports/
+/tmp/

data/.rubocop.yml

@@ -0,0 +1,2 @@
+inherit_from:
+  - default.yml

data/CHANGELOG.md

@@ -0,0 +1,23 @@
+# Changelog
+
+## [1.0.2](https://github.com/sequra/sequra-style/compare/v1.0.1...v1.0.2) (2024-03-15)
+
+
+### Bug Fixes
+
+* add note about severity level for restricting changes ([#23](https://github.com/sequra/sequra-style/issues/23)) ([9978874](https://github.com/sequra/sequra-style/commit/99788746845c79e9e7239edd49df1286a9e38a5f))
+
+## [1.0.1](https://github.com/sequra/sequra-style/compare/v1.0.0...v1.0.1) (2024-03-14)
+
+
+### Bug Fixes
+
+* Allow pushing gem to rubygems.pkg.github.com ([#20](https://github.com/sequra/sequra-style/issues/20)) ([df7191f](https://github.com/sequra/sequra-style/commit/df7191f7f212d416a4531d358b27769d45458cda))
+
+## 1.0.0 (2024-03-12)
+
+
+### Features
+
+* Initial release ([0b5898c](https://github.com/sequra/sequra-style/commit/0b5898ce8dd54b2570a4eac51d5352c74f484570))
+* initial release ([#18](https://github.com/sequra/sequra-style/issues/18)) ([ef46dac](https://github.com/sequra/sequra-style/commit/ef46dac4b7f6e1d6bbe89c155bb673219a0e30ba))

data/Gemfile

@@ -0,0 +1,6 @@
+source "https://rubygems.org"
+
+git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }
+
+# Specify your gem's dependencies in sequra-style.gemspec
+gemspec

data/Gemfile.lock

@@ -0,0 +1,67 @@
+PATH
+  remote: .
+  specs:
+    sequra-style (1.0.2)
+      rubocop (~> 1)
+      rubocop-performance (~> 1)
+      rubocop-rails (~> 2)
+      rubocop-rspec (~> 2)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    activesupport (7.0.4)
+      concurrent-ruby (~> 1.0, >= 1.0.2)
+      i18n (>= 1.6, < 2)
+      minitest (>= 5.1)
+      tzinfo (~> 2.0)
+    ast (2.4.2)
+    concurrent-ruby (1.1.10)
+    i18n (1.12.0)
+      concurrent-ruby (~> 1.0)
+    json (2.6.2)
+    minitest (5.16.3)
+    parallel (1.22.1)
+    parser (3.1.2.1)
+      ast (~> 2.4.1)
+    rack (3.0.0)
+    rainbow (3.1.1)
+    rake (13.0.6)
+    regexp_parser (2.6.1)
+    rexml (3.2.5)
+    rubocop (1.39.0)
+      json (~> 2.3)
+      parallel (~> 1.10)
+      parser (>= 3.1.2.1)
+      rainbow (>= 2.2.2, < 4.0)
+      regexp_parser (>= 1.8, < 3.0)
+      rexml (>= 3.2.5, < 4.0)
+      rubocop-ast (>= 1.23.0, < 2.0)
+      ruby-progressbar (~> 1.7)
+      unicode-display_width (>= 1.4.0, < 3.0)
+    rubocop-ast (1.23.0)
+      parser (>= 3.1.1.0)
+    rubocop-performance (1.15.1)
+      rubocop (>= 1.7.0, < 2.0)
+      rubocop-ast (>= 0.4.0)
+    rubocop-rails (2.17.2)
+      activesupport (>= 4.2.0)
+      rack (>= 1.1)
+      rubocop (>= 1.33.0, < 2.0)
+    rubocop-rspec (2.15.0)
+      rubocop (~> 1.33)
+    ruby-progressbar (1.11.0)
+    tzinfo (2.0.5)
+      concurrent-ruby (~> 1.0)
+    unicode-display_width (2.3.0)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  bundler (~> 2.1.4)
+  rake (~> 13.0.1)
+  sequra-style!
+
+BUNDLED WITH
+   2.1.4

data/LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2014 Joel Junström
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

data/README.md

@@ -0,0 +1,27 @@
+# sequra-style
+
+SeQura code style guide and shared configuration.
+
+## Installation
+
+Add this line to your application's Gemfile (we need to point to GitHub since it's not published):
+
+```ruby
+gem "sequra-style", git: "https://github.com/sequra/sequra-style", require: false
+```
+
+And then execute:
+
+```shell
+$ bundle install
+```
+
+## Usage
+
+Use the following directives in a `.rubocop.yml` file:
+
+```yaml
+inherit_gem:
+  sequra-style:
+    - default.yml
+```

data/Rakefile

@@ -0,0 +1 @@
+require "bundler/gem_tasks"

data/bin/console

@@ -0,0 +1,14 @@
+#!/usr/bin/env ruby
+
+require "bundler/setup"
+require "sequra/style"
+
+# You can add fixtures and/or initialization code here to make experimenting
+# with your gem easier. You can also use a different console, if you like.
+
+# (If you use this, don't forget to add pry to your Gemfile!)
+# require "pry"
+# Pry.start
+
+require "irb"
+IRB.start(__FILE__)

data/bin/setup

@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+set -euo pipefail
+IFS=$'\n\t'
+set -vx
+
+bundle install
+
+# Do any other automated setup that you need to do here

data/default.yml

@@ -0,0 +1,287 @@
+require:
+  - rubocop-performance
+  - rubocop-rails
+  - rubocop-rspec
+
+AllCops:
+  # RuboCop has a bunch of cops enabled by default. This setting tells RuboCop
+  # to ignore them, so only the ones explicitly set in this file are enabled.
+  DisabledByDefault: true
+  Exclude:
+    - "**/vendor/**/*"
+    - "**/node_modules/**/*"
+    - "local_files/**/*"
+  NewCops: disable
+
+Performance:
+  Enabled: true
+  Exclude:
+    - "**/spec/**/*"
+
+Rails:
+  Enabled: true
+
+# Prefer assert_not over assert !
+Rails/AssertNot:
+  Include:
+    - "**/spec/**/*"
+
+# Don't enforce tag over content tag until this issue is properly handled:
+# https://github.com/rubocop-hq/rubocop-rails/issues/260
+Rails/ContentTag:
+  Enabled: false
+
+Rails/FilePath:
+  EnforcedStyle: "arguments"
+
+# Prefer assert_not_x over refute_x
+Rails/RefuteMethods:
+  Include:
+    - "**/spec/**/*"
+
+Rails/TimeZone:
+  Enabled: true
+
+# Prefer &&/|| over and/or.
+Style/AndOr:
+  Enabled: true
+
+Style/DateTime:
+  Enabled: true
+
+Style/MultilineIfModifier:
+  Enabled: true
+
+Style/NestedModifier:
+  Enabled: true
+
+Style/SoleNestedConditional:
+  Enabled: true
+
+# Align `when` with `case`.
+Layout/CaseIndentation:
+  Enabled: true
+
+Layout/ClassStructure:
+  Enabled: true
+  ExpectedOrder:
+     - module_inclusion
+     - constants
+     - association
+     - public_attribute_macros
+     - public_delegate
+     - macros
+     - public_class_methods
+     - initializer
+     - public_methods
+     - protected_attribute_macros
+     - protected_methods
+     - private_attribute_macros
+     - private_delegate
+     - private_methods
+  Categories:
+     association:
+       - has_many
+       - has_one
+     attribute_macros:
+       - attr_accessor
+       - attr_reader
+       - attr_writer
+     macros:
+       - validates
+       - validate
+     module_inclusion:
+       - include
+       - prepend
+       - extend
+
+# Align comments with method definitions.
+Layout/CommentIndentation:
+  Enabled: true
+
+Layout/ElseAlignment:
+  Enabled: true
+
+# Align `end` with the matching keyword or starting expression except for
+# assignments, where it should be aligned with the LHS.
+Layout/EndAlignment:
+  Enabled: true
+  EnforcedStyleAlignWith: variable
+  AutoCorrect: true
+
+Layout/EmptyLineAfterMagicComment:
+  Enabled: true
+
+Layout/EmptyLinesAroundBlockBody:
+  Enabled: true
+
+# In a regular class definition, no empty lines around the body.
+Layout/EmptyLinesAroundClassBody:
+  Enabled: true
+
+# In a regular method definition, no empty lines around the body.
+Layout/EmptyLinesAroundMethodBody:
+  Enabled: true
+
+# In a regular module definition, no empty lines around the body.
+Layout/EmptyLinesAroundModuleBody:
+  Enabled: true
+
+Layout/FirstArgumentIndentation:
+  Enabled: true
+
+# Use Ruby >= 1.9 syntax for hashes. Prefer { a: :b } over { :a => :b }.
+Style/HashSyntax:
+  Enabled: true
+
+# Method definitions after `private` or `protected` isolated calls need one
+# extra level of indentation.
+Layout/IndentationConsistency:
+  Enabled: true
+  EnforcedStyle: indented_internal_methods
+
+# Two spaces, no tabs (for indentation).
+Layout/IndentationWidth:
+  Enabled: true
+
+Layout/LeadingCommentSpace:
+  Enabled: true
+
+Layout/SpaceAfterColon:
+  Enabled: true
+
+Layout/SpaceAfterComma:
+  Enabled: true
+
+Layout/SpaceAroundEqualsInParameterDefault:
+  Enabled: true
+
+Layout/SpaceAroundKeyword:
+  Enabled: true
+
+Layout/SpaceAroundOperators:
+  Enabled: true
+
+Layout/SpaceBeforeComma:
+  Enabled: true
+
+Layout/SpaceBeforeComment:
+  Enabled: true
+
+Layout/SpaceBeforeFirstArg:
+  Enabled: true
+  Exclude:
+    - "**/spec/**/*"
+
+Style/DefWithParentheses:
+  Enabled: true
+
+# Defining a method with parameters needs parentheses.
+Style/MethodDefParentheses:
+  Enabled: true
+
+Style/FrozenStringLiteralComment:
+  Enabled: false
+  EnforcedStyle: always
+
+Layout/LineLength:
+  Enabled: true
+  Max: 128
+
+# Use `foo {}` not `foo{}`.
+Layout/SpaceBeforeBlockBraces:
+  Enabled: true
+
+# Use `foo { bar }` not `foo {bar}`.
+Layout/SpaceInsideBlockBraces:
+  Enabled: true
+
+# Use `{ a: 1 }` not `{a:1}`.
+Layout/SpaceInsideHashLiteralBraces:
+  Enabled: true
+
+Layout/SpaceInsideParens:
+  Enabled: true
+
+# Check quotes usage according to lint rule below.
+Style/StringLiterals:
+  Enabled: true
+  EnforcedStyle: double_quotes
+
+# Detect hard tabs, no hard tabs.
+Layout/IndentationStyle:
+  Enabled: true
+
+# Blank lines should not have any spaces.
+Layout/TrailingEmptyLines:
+  Enabled: true
+
+# No trailing whitespace.
+Layout/TrailingWhitespace:
+  Enabled: true
+
+Lint/Debugger:
+  Enabled: true
+
+# Use quotes for string literals when they are enough.
+Style/RedundantPercentQ:
+  Enabled: true
+
+# Use my_method(my_arg) not my_method( my_arg ) or my_method my_arg.
+Lint/RequireParentheses:
+  Enabled: true
+
+Lint/RedundantStringCoercion:
+  Enabled: true
+
+Lint/UriEscapeUnescape:
+  Enabled: true
+
+Style/ParenthesesAroundCondition:
+  Enabled: true
+
+Style/RedundantReturn:
+  Enabled: true
+  AllowMultipleReturnValues: true
+
+Style/Semicolon:
+  Enabled: true
+  AllowAsExpressionSeparator: true
+
+# Prefer Foo.method over Foo::method
+Style/ColonMethodCall:
+  Enabled: true
+
+Style/TrivialAccessors:
+  Enabled: true
+
+# Use guard clauses when possible
+Style/GuardClause:
+  Enabled: true
+
+Performance/FlatMap:
+  Enabled: true
+
+Performance/RedundantMerge:
+  Enabled: true
+
+Performance/StartWith:
+  Enabled: true
+
+Performance/EndWith:
+  Enabled: true
+
+Performance/RegexpMatch:
+  Enabled: true
+
+RSpec/ContextWording:
+  Enabled: false
+
+RSpec/ExampleLength:
+  Max: 16
+
+RSpec/MultipleExpectations:
+  Enabled: false
+
+RSpec/NestedGroups:
+  Enabled: false

data/docs/decisions/2022-10-25-use-markdown-architectural-decision-records.md

@@ -0,0 +1,170 @@
+# Use Markdown Architectural Decision Records
+An architecture decision record (ADR) is a document that captures an important architecture decision made along with its context and consequences.
+
+---
+**💡 Proposed 💡**
+* **Deciders:** @franmosteiro, @jaimevelaz
+* **Proposal date:** 25/10/2022
+* **Due date:** 01/11/2022
+* **Technical information:** None
+
+---
+### Contents
+* [Context and Problem Statement](./##context-and-problem-statement)
+* [Decision Drivers](./##decision-drivers)
+* [Considered Options](./##considered-options)
+* [Decision Outcome](./##decision-outcome)
+  * [ADR file name conventions](./###adr-file-name-conventions)
+  * [Suggestions for writing good ADRs](./###suggestions-for-writing-good-adrs)
+* [Credits](./##credits)
+
+## Context and Problem Statement
+### Context
+As the team grows, we find that there is a growing need for documenting better and more the technical decisions we make in our services.
+
+This is not important just to the current people in the teams, or to the ones to come and even for our future ourselves when we need to recheck why we did something or how we decided something, but also for other teams and coworkers to reflect their own decisions and this way, finding some kind of alignment in the technical part without patronizing the autonomy in the teams.
+
+In short, trying to maintain a good balance between them: autonomy, pragmatism, and a similar stack.
+
+### Hypothesis
+We think that by providing some base templating for **ADR generation** and using them for our services design decisions, we can make this goal of documenting more and better relatively easier, simpler, faster and ultimately more straightforward for teams, so they will only have to make use of them when creating a new feature or iterating older ones.
+
+### Experiment
+We propose using **ADRs** as a tool that **might help us document our technical and design decisions more and better**. And also we think that the best place to place them is near the code, using them as another good way to understand the bigger picture before jumping into the tests and production code to get the detail of the things documented in the ADRs firstly.
+
+Of course, this will be an initial approach and we expect the template to evolve and grow with the collaboration, experience and necessities of any of the teams! 😊
+
+## Decision Drivers
+* Incremental growth in the size and number of teams and services.
+* Lack of context on other teams owned services, tracing, telemetry etc.
+* Lack of context in decision-making and overall direction of services.
+* Looking to improve cross-team collaboration.
+* Need to enable teams to understand the bigger picture.
+
+## Considered Options
+* Use Google Drive and its online editing capabilities, through a Google Doc or Google Sheet.
+* Use Atlassian Jira, through the tool's planning tracker.
+* Use Atlassian Confluence (wiki) and create wiki-style ADRs.
+* Making use of source code version control, such as git, we could create a file for each ADR nearest to the code.
+  * [MADR](https://adr.github.io/madr/) 2.1.2 – The Markdown Architectural Decision Records.
+  * [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR".
+  * [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements.
+  * Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
+  * Formless – No conventions for file format and structure.
+
+## Decision Outcome
+We want to record architectural decisions made in this project.
+
+**Which format and structure should these records follow?**
+
+**Choosen option:** ADRs and in particular the [MADR model](https://adr.github.io/madr/)(without the tooling), because
+
+* Implicit assumptions should be made explicit.
+  Design documentation is important to enable people to understand the decisions later on.  
+  See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
+* The MADR format is lean and fits our development style.
+* The MADR structure is comprehensible and facilitates usage & maintenance.
+* The MADR project is vivid.
+
+### ADR ownership and execution
+**Ownership** of the ADR during the drafting and validation process **belongs to the persons/teams that originally initiated it.**
+
+Among other things, **they will be responsible for:**
+
+* **Communicate**, through the necessary and appropriate channels and as many times as necessary, the entire content of the ADR (even before it is finalised or closed, in draft).
+
+* **Obtain the buy-in** of the interlocutors and/or teams involved in the change or improvement proposed by the ADR, including stakeholders, if applicable.
+
+* **By consent** (this means that there is no more appropriate or better proposal, so we go with this one), **the tech team should be aligned and aware** of the step with this new ADR and become part of their own technical decisions.
+
+* **Be advocates of the idea** behind the ADR even after it has gone live, **reminding and helping new teams and colleagues to keep it relevant in their designs.**
+
+### ADR file name conventions
+If you choose to create your ADRs using typical text files, then you may want to come up with your own ADR file name convention.
+
+We prefer to use a file name convention that has a specific format. Based on [this other ADR in Simba](https://github.com/sequra/simba/blob/master/adr/2022-03-10-adr-ids-timestamps.md), we will choose this format:
+
+* yyyy-mm-dd-choose-database.md
+* yyyy-mm-dd-format-timestamps.md
+* yyyy-mm-dd-manage-passwords.md
+* yyyy-mm-dd-handle-exceptions.md
+
+Our file name convention:
+
+* Date of creation: yyyy-mm-dd
+* The name has a present tense imperative verb phrase. This helps readability and matches our commit message format.
+* The name uses lowercase and dashes (same as this repo). This is a balance of readability and system usability.
+* The extension is markdown. This can be useful for easy formatting.
+
+### ADR workflow suggestion
+```text
+⚠️ This is just a suggested workflow. The choosed workflow may depend on the necessities your team has around the ADR: sharing an idea, sharing an idea with some Proof of Concept, sharing the implementation of a new design approach etc.
+```
+
+1. Share a new **P**ull**R**equest including the ADR in the docs/decisions folder, to start the conversation with the related teams/peers.
+
+2. Start the conversation on this first PR until it is “accepted” or “rejected”. Meanwhile, add in this PR (or in another one related somehow to the ADR PR) the proposed changes.
+
+3. Before closing the PR containing the ADR, remember to update it with the correct status and the final decisions taken regarding the comments of the rest of the team.
+
+```text
+ℹ️ These are just suggestion. Please, feel encouraged to set the workflow better fits within your concrete necessities and let’s learn with the process
+```
+
+### ADR ‘status’ changes
+An ADR can go through these different states:
+
+* **🚧 WIP 🚧:** still working on the ADR, not yet released.
+* **💡 Proposed 💡:** already proposed to the team.
+* **🚫 Rejected 🚫:** the team has rejected the ADR, but we save it for traceability.
+* **✅ Accepted ✅:** the team has accepted the ADR.
+* **🕸 Deprecated 🕸:** the ADR has been deprecated (ex: tech stack change, library deprecation etc).
+* **🌱 Superseded by ADR-202x-xx-xx 🌱:** if an ADR supersedes an older ADR then the status of the older ADR is changed to "superseded by ADR-yyyy-mm-dd", and links to the new ADR.
+
+#### How do we know when an ADR is accepted/rejected
+There are several mechanisms that will allow us to know whether an ADR is accepted or not.  
+As a starting point, there are **two scenarios**:
+
+* The **ADR has a due date**: which means that it needs to be resolved by that date at the latest.
+* The **ADR does not have a due date**.
+
+Regardless of the starting point, there are a number of mechanisms that will allow us to know whether or not an ADR is accepted by the due date (whether closed or not).
+
+```text
+📝 Once shared with the team, we will review acceptance ideally on the basis of consensus, although we will accept consent if the lack of feedback/interactions in the team is significant and the change is reversible (1).
+```
+
+#### Artifacts to review:
+* If there is explicit approval ✅ in the PRs, at least, from the owner team (in the PR including the ADR).
+* If there are **opinions against** the ADR, they must be justified in the comments and have **explicit RC** (request changes) **PR reviews ⛔**
+* If there are still unresolved discussions against the ADR idea or, if there are, they have been resolved.
+
+```text
+📝 Once all the information has been reviewed or if the due date arrives, we will transition the ADR to the appropriate status: accepted or rejected.
+```
+
+### Suggestions for writing good ADRs
+Characteristics of a good ADR:
+* Rational: Explain the reasons for doing the particular AD. This can include the context (see below), pros and cons of various potential choices, feature comparisons, cost/benefit discussions, and more.
+* Specific: Each ADR should be about one AD, not multiple ADs.
+* Timestamps: Identify when each item in the ADR is written. This is especially important for aspects that may change over time, such as costs, schedules, scaling, and the like.
+* Immutable: Don't alter existing information in an ADR. Instead, amend the ADR by adding new information, or supersede the ADR by creating a new ADR.
+
+Characteristics of a good "Context" section in an ADR:
+* Explain your organization's situation and business priorities.
+* Include rationale and considerations based on social and skills makeup of your teams.
+* Include pros and cons that are relevant, and describe them in terms that align with your needs and goals.
+
+Characteristics of good "Consequences" section in an ADR:
+* Explain what follows from making the decision. This can include the effects, outcomes, outputs, follow-ups, and more.
+* Include information about any subsequent ADRs. It's relatively common for one ADR to trigger the need for more ADRs, such as when one ADR makes a big overarching choice, which in turn creates the need for smaller decisions.
+* Include any after-action review processes. It's typical for teams to review each ADR one month later, to compare the ADR information with what's happened in actual practice, to learn and grow.
+
+A new ADR may take the place of a previous ADR:
+* When an AD is made that replaces or invalidates a previous ADR, then a new ADR should be created.
+
+## Credits
+KUDOS to Joel Parker for sharing all this knowledge with us through [this repo](https://github.com/joelparkerhenderson/architecture-decision-record).
+
+## Links
+[(1) Reversible changes](https://www.businessinsider.com/amazon-jeff-bezos-letter-reversible-decisions-1997-hq2-new-york-2019-2?op=1)

data/docs/decisions/README.md

@@ -0,0 +1,4 @@
+# Architectural design records
+The idea is to provide a basic integrated ADR generation for #{your project}
+  - You can see an [index of ADRs here](./index.md)
+  - You can see the [base template here](./template.md)

data/docs/decisions/index.md

@@ -0,0 +1,7 @@
+# Architectural Decision Log
+
+This log lists the architectural decisions for [project name].
+
+* [ADR-2022-10-25](2022-10-25-use-markdown-architectural-decision-records.md) - Architectural Decision Records as a way for documenting design decisions
+
+For new ADRs, please use [template.md](template.md) as basis.

data/docs/decisions/template.md

@@ -0,0 +1,102 @@
+✂✂✂✂✂< REMOVE FROM THIS PART BEFORE SUBMITTING YOUR ADR ✂✂✂✂✂
+# ⚠️ Should this be an ADR?
+Are you in doubt if this document you or your team propose needs to be an Architectural Decision Record?
+
+Let's check it through several questions 😊
+
+Starting with a `stop question`:
+
+* ❓ Is this ADR related to a change in this specific application or service?
+✋ **If** the answer **is "no"**, which means that this ADR affects this application and others, **end this document here** and start writing a general Decision Record [here](https://sequra.atlassian.net/wiki/spaces/EN/pages/3771039771/Tech+Decision+Records#List-of-Tech-Decision-Records)
+👇 **If** the previous **answer is a "yes"**
+
+Let's **continue** with these other questions:
+
+* ❓ Will this ADR provoke a breaking changes or sensible modifications inside this application or services' engine, interfaces, APIs or [seams](https://archive.org/details/working-effectively-with-legacy-code/page/n51/mode/2up) `(look into chapter 4 of this book for the reference)` between domains?
+* ❓ Will this ADR introduce new architectural or software design patterns in the project (f.ex: big refactors which provide that an old feature can work in a new way, introducing a new technology/gem/package/etc ...)
+* ❓ Will this ADR impact other teams’ roadmaps or velocities meaningfully?
+* ❓ Does this ADR imply different approaches/options for which you want/need the opinion of the rest of the team?
+* ❓ Does this ADR modify/impact another existing or very similar ADR (superseeding or refining it)?
+
+Then, evaluate your answers:
+
+* 👉  If you checked any of those boxes, this topic does need an ADR.
+* 👉  If you didn’t check any of those boxes, doing an ADR is optional.
+
+**❗  Depending on your decision, either delete this section or delete this document!**
+
+✂✂✂✂✂< REMOVE FROM THIS PART BEFORE SUBMITTING YOUR ADR ✂✂✂✂✂
+
+# [short title of solved problem and solution]
+
+---
+* **Status:** [🚧🌱 wip | 💡 proposed | 🚫 rejected | ✅ accepted | 🕸 deprecated | … | ⬆️🌱 superseded by [ADR-0005](0005-example.md)] <!-- optional -->
+* **Deciders:** [list everyone involved in the decision] <!-- optional -->
+* **Proposal date:** [YYYY-MM-DD when the decision was proposed] <!-- optional -->
+* **Due date:** [YYYY-MM-DD when the decision is finally made] <!-- optional -->
+* **Technical Story:** [description | ticket/issue URL] <!-- optional -->
+---
+## Context and Problem Statement
+
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+
+## Decision Drivers <!-- optional -->
+
+* [driver 1, e.g., a force, facing concern, …]
+* [driver 2, e.g., a force, facing concern, …]
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* [option 1]
+* [option 2]
+* [option 3]
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+
+### Positive Consequences <!-- optional -->
+
+* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
+* …
+
+### Negative Consequences <!-- optional -->
+
+* [e.g., compromising quality attribute, follow-up decisions required, …]
+* …
+
+## Pros and Cons of the Options <!-- optional -->
+
+### [option 1]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 2]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 3]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+## Links <!-- optional -->
+
+* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->

data/lib/sequra/style/version.rb

@@ -0,0 +1,5 @@
+module Sequra
+  module Style
+    VERSION = "0.2.0"
+  end
+end

data/lib/sequra/style.rb

@@ -0,0 +1,7 @@
+require "sequra/style/version"
+
+module Sequra
+  module Style
+    # Just a namespace...
+  end
+end

data/sequra-style.gemspec

@@ -0,0 +1,31 @@
+lib = File.expand_path("../lib", __FILE__)
+$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
+require "sequra/style/version"
+
+Gem::Specification.new do |spec|
+  spec.name          = "sequra-style"
+  spec.version       = Sequra::Style::VERSION
+  spec.authors       = ["Sequra engineering"]
+  spec.email         = ["rubygems@sequra.es"]
+
+  spec.summary       = "Sequra code style guides and shared config"
+  spec.homepage      = "https://github.com/sequra/sequra-style"
+  spec.license       = "MIT"
+
+  # Specify which files should be added to the gem when it is released.
+  # The `git ls-files -z` loads the files in the RubyGem that have been added into git.
+  spec.files = Dir.chdir(File.expand_path("..", __FILE__)) do
+    `git ls-files -z`.split("\x0").reject { |f| f.match(%r{^(test|spec|features)/}) }
+  end
+  spec.bindir        = "exe"
+  spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
+  spec.require_paths = ["lib"]
+
+  spec.add_dependency "rubocop", "~> 1"
+  spec.add_dependency "rubocop-performance", "~> 1"
+  spec.add_dependency "rubocop-rails", "~> 2"
+  spec.add_dependency "rubocop-rspec", "~> 2"
+
+  spec.add_development_dependency "bundler", "~> 2.1.4"
+  spec.add_development_dependency "rake", "~> 13.0.1"
+end

metadata

@@ -0,0 +1,149 @@
+--- !ruby/object:Gem::Specification
+name: sequra-style
+version: !ruby/object:Gem::Version
+  version: 0.2.0
+platform: ruby
+authors:
+- Sequra engineering
+autorequire: 
+bindir: exe
+cert_chain: []
+date: 2024-03-15 00:00:00.000000000 Z
+dependencies:
+- !ruby/object:Gem::Dependency
+  name: rubocop
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1'
+- !ruby/object:Gem::Dependency
+  name: rubocop-performance
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1'
+- !ruby/object:Gem::Dependency
+  name: rubocop-rails
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '2'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '2'
+- !ruby/object:Gem::Dependency
+  name: rubocop-rspec
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '2'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '2'
+- !ruby/object:Gem::Dependency
+  name: bundler
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 2.1.4
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 2.1.4
+- !ruby/object:Gem::Dependency
+  name: rake
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 13.0.1
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 13.0.1
+description: 
+email:
+- rubygems@sequra.es
+executables: []
+extensions: []
+extra_rdoc_files: []
+files:
+- ".github/CODEOWNERS"
+- ".github/PULL_REQUEST_TEMPLATE.md"
+- ".github/workflows/pr_title_validation.yml"
+- ".github/workflows/release.yml"
+- ".gitignore"
+- ".rubocop.yml"
+- CHANGELOG.md
+- Gemfile
+- Gemfile.lock
+- LICENSE
+- README.md
+- Rakefile
+- bin/console
+- bin/setup
+- default.yml
+- docs/decisions/2022-10-25-use-markdown-architectural-decision-records.md
+- docs/decisions/README.md
+- docs/decisions/index.md
+- docs/decisions/template.md
+- lib/sequra/style.rb
+- lib/sequra/style/version.rb
+- sequra-style.gemspec
+homepage: https://github.com/sequra/sequra-style
+licenses:
+- MIT
+metadata: {}
+post_install_message: 
+rdoc_options: []
+require_paths:
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+required_rubygems_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+requirements: []
+rubygems_version: 3.4.19
+signing_key: 
+specification_version: 4
+summary: Sequra code style guides and shared config
+test_files: []