QT/sure

mirror of https://github.com/we-promise/sure.git synced 2026-09-08 16:14:23 +00:00

Files

T

Juan José Mata 157daf5176 Consolidate repository instructions after auditing their history (#3409 )

* Document instruction inventory and preservation decisions

Trace main history from September 2025 through September 2026, including earlier policy origins. Record preserved requirements, detailed-guide destinations, stale facts, harness boundaries and explicit policy-strength decisions before consolidating instruction sources.

* Consolidate repository instructions into shared guidance

Keep AGENTS concise and vendor neutral, move detailed conventions into shared guides, and use thin adapters with preserved Cursor scopes. Preserve the strict pre-PR checks globally and document the stronger scope, retired migration pin and rule-generation trigger. Update existing API guidance verification without changing application behavior.

* Narrow the always-on Cursor UI adapter and correct the SimpleFIN comment

Split the design-system guidance out of docs/llm-guides/ui.md into
docs/llm-guides/design-system.md. The ui-ux-design-guidelines rule is
alwaysApply: true, so importing all of ui.md loaded the Stimulus,
localization and ViewComponent guidance (previously confined to scoped
rules) on every Cursor session; the always-on adapter now imports only the
design-system guide, matching the scope it had before the consolidation.
view_conventions and stimulus_conventions keep the full UI guide.

Also correct the stale Provider::Simplefin header comment: pending
inclusion defaults on and is resolved by the importer (explicit argument,
then SIMPLEFIN_INCLUDE_PENDING, then Setting.syncs_include_pending); the
previous comment described the flag as default-off.

* Read guidance files as UTF-8 in the API consistency validators

The frontmatter regex match ran against content read with the locale
default external encoding; the Cursor rule's description contains an em
dash, so under US-ASCII (LC_ALL=C) Regexp#match raised ArgumentError,
breaking the standalone no-Rails fallback the docs point contributors to.
Read all checked files with an explicit UTF-8 encoding in both the
standalone script and the Rails test.

2026-09-06 07:14:43 +02:00

3.9 KiB

Raw Blame History

Contributing to Sure

It means so much that you're interested in contributing to Sure! Seriously. Thank you. The entire community benefits from these contributions!

House Rules

Before contributing, read the repository guidance and architecture and conventions. Detailed task guides cover testing, UI, APIs and providers.
Coding-assistant setup is optional; see the supported instruction adapters.
Before contributing, please check if it already exists in issues or PRs
Given the speed at which we're moving on the codebase, we don't assign issues or "give" issues to anyone.
When multiple PRs are submitted for the same issue, we take the one that most succinctly & efficiently solves a given problem and stays within the scope of work.
Priority is generally given to previous committers as they've proven familiarity with the codebase and product.

What should I contribute?

As we are still in the early days of this project, we recommend heading over to the Wiki to get a better idea of what to contribute.

In general, full features that get us closer to our 🔜 Vision are the most valuable contributions at this stage.

Development

Setup

To get setup for local development, you have two options:

Dev Containers with VSCode (see the .devcontainer folder)
- A selenium/standalone-chrome service is included in the Dev Container setup, so system tests work out of the box — no local Chrome required.
- Run system tests: DISABLE_PARALLELIZATION=true bin/rails test:system
- Watch the browser live at http://localhost:7900 or http://localhost:4444 (password: secret)
Local Development

Making a Pull Request

Fork the repo
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Add some feature')
Push to the branch (git push origin my-new-feature)
Create new Pull Request, and be sure to check the Allow edits from maintainers option while creating your PR. This allows maintainers to collaborate with you on your PR if needed.
If possible, link your pull request to an issue by adding the appropriate keyword (e.g. fixes issue #XXX)
Before requesting a review, please make sure that all Github Checks have passed and your branch is up-to-date with the main branch. After doing so, request a review and wait for a maintainer's approval.

All PRs should target the main branch.

Automated Security Scanning

Every pull request to the main branch automatically runs a Pipelock security scan. This scan analyzes your PR diff for:

Leaked secrets (API keys, tokens, credentials)
Agent security risks (misconfigurations, exposed credentials, missing controls)

The scan runs as part of the CI pipeline and typically completes in ~30 seconds. If security issues are found, the CI check will fail. You don't need to configure anything—the security scanning is automatic and zero-configuration.

3.9 KiB Raw Blame History