docs: add governance, support, DCO and security assurance case (#164)

Add GOVERNANCE.md, MAINTAINERS.md, SUPPORT.md, DCO; add a DCO sign-off requirement to CONTRIBUTING.md and a security assurance case to SECURITY.md. Closes OpenSSF Silver / OSPS Baseline documentation gaps. Additive only.

CONTRIBUTING.md

@@ -122,3 +122,33 @@ installed. Dependabot also keeps the `.github/requirements` pins current.
 Use the issue templates under
 [`.github/ISSUE_TEMPLATE`](.github/ISSUE_TEMPLATE). For security-sensitive
 reports, follow [`SECURITY.md`](SECURITY.md) instead of opening a public issue.
+
+## Developer Certificate of Origin (DCO)
+
+All contributions to Wickra are made under the [Developer Certificate of
+Origin (DCO) 1.1](DCO). By signing off on your commits you certify that you
+wrote the patch, or otherwise have the right to submit it under the project's
+`MIT OR Apache-2.0` license.
+
+Sign off every commit by adding a `Signed-off-by` trailer with your real name
+and email — Git adds it automatically with the `-s` flag:
+
+```bash
+git commit -s -m "your message"
+```
+
+This produces a trailer of the form:
+
+```
+Signed-off-by: Your Name <you@example.com>
+```
+
+The name and email must match the commit author. Commits without a valid
+sign-off line cannot be merged. To sign off a commit you already made, amend it
+with `git commit -s --amend`, or sign off a range with an interactive rebase.
+
+## Governance
+
+Wickra's decision-making and maintainership are described in
+[`GOVERNANCE.md`](GOVERNANCE.md); the current maintainers are listed in
+[`MAINTAINERS.md`](MAINTAINERS.md).

DCO

@@ -0,0 +1,34 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.

GOVERNANCE.md

@@ -0,0 +1,50 @@
+# Governance
+
+Wickra is an open-source project maintained under a **single-maintainer
+("BDFL") model**. This document describes how decisions are made and how the
+project is run, so contributors know what to expect.
+
+## Roles
+
+- **Maintainer.** The maintainer (see [`MAINTAINERS.md`](MAINTAINERS.md)) is
+  responsible for the project's direction, reviews and merges changes, cuts
+  releases, and has final say on all technical and project decisions.
+- **Contributors.** Anyone who proposes changes via pull requests, files
+  issues, improves documentation, or otherwise participates. Contributors do
+  not need any special status to take part.
+
+## Decision-making
+
+- Day-to-day technical decisions (APIs, indicator implementations, refactors)
+  are made by the maintainer, informed by discussion on issues and pull
+  requests.
+- Proposals are raised as GitHub issues or pull requests. Significant or
+  breaking changes should be opened as an issue first to agree on the approach
+  before implementation.
+- The maintainer aims to act transparently: rationale for non-trivial decisions
+  is recorded in the relevant issue, pull request, or commit message.
+
+## Contribution flow
+
+All changes — including the maintainer's own — go through pull requests so that
+CI (tests, linting, static analysis) runs against them, and so the change
+history is reviewable. Contribution requirements are documented in
+[`CONTRIBUTING.md`](CONTRIBUTING.md), including the Developer Certificate of
+Origin sign-off that every commit must carry.
+
+## Becoming a maintainer
+
+The project currently has one maintainer. Maintainership may be extended to
+contributors who have demonstrated sustained, high-quality involvement, at the
+current maintainer's discretion. If the project grows to multiple maintainers,
+this document will be updated to describe shared decision-making.
+
+## Code of conduct
+
+All participants are expected to follow the
+[Code of Conduct](CODE_OF_CONDUCT.md).
+
+## Changes to this document
+
+This governance model may evolve as the project grows. Changes are made via
+pull request and take effect once merged.

MAINTAINERS.md

@@ -0,0 +1,17 @@
+# Maintainers
+
+This file lists the current maintainers of Wickra. See
+[`GOVERNANCE.md`](GOVERNANCE.md) for what the role entails and how the project
+is run.
+
+| Maintainer | GitHub | Areas |
+| --- | --- | --- |
+| kingchenc | [@kingchenc](https://github.com/kingchenc) | All (core, bindings, CI/release, docs) |
+
+## Contacting the maintainers
+
+- General questions and support: see [`SUPPORT.md`](SUPPORT.md).
+- Bug reports and feature requests: open an issue using the
+  [issue templates](.github/ISSUE_TEMPLATE).
+- Security reports: follow [`SECURITY.md`](SECURITY.md) — do **not** open a
+  public issue.

SECURITY.md

@@ -41,3 +41,38 @@ PyPI/npm packages, and the build/release workflows in `.github/workflows/`.
 
 Out of scope: vulnerabilities in third-party dependencies (report those
 upstream; we track them via Dependabot and `cargo-deny`).
+
+## Security assurance case
+
+This is a short, evidence-backed argument for why Wickra can be used safely.
+
+**Security requirements.** Wickra is a computational library: it ingests
+numeric market data and produces indicator values. It stores no user
+credentials, authenticates no external users, and implements no cryptography of
+its own. The requirements are therefore: (1) memory safety and freedom from
+undefined behaviour, (2) robust handling of untrusted/degenerate numeric input
+without panics or unbounded resource use, (3) integrity of the published
+artifacts, and (4) a healthy dependency supply chain.
+
+**How the requirements are met.**
+
+- *Memory safety* — the core and all bindings are written in Rust. The crates
+  forbid or minimise `unsafe`, so the compiler guarantees memory and thread
+  safety for the indicator logic.
+- *Input robustness* — every indicator validates its parameters and rejects
+  non-finite inputs at construction; behaviour on edge cases (flat markets,
+  warmup, reset) is pinned by unit tests, and the public update paths are
+  exercised by coverage-guided fuzzing (`cargo-fuzz` / libFuzzer) in CI.
+- *Static and dynamic analysis* — every push and pull request runs Clippy
+  (`clippy::pedantic`, warnings-as-errors), CodeQL, fuzzing, and the full test
+  suite, with 100% line coverage on the core crate tracked by Codecov.
+- *Artifact integrity* — releases are built in CI, commits and tags are signed,
+  the `main` branch requires signed commits, and release artifacts carry build
+  provenance attestations.
+- *Supply chain* — dependencies are pinned and monitored with Dependabot and
+  audited with `cargo-deny` (license + advisory checks) on every change.
+
+**Residual risk.** The optional `live-binance` feature opens a TLS WebSocket to
+an exchange using the platform TLS library; transport security therefore
+depends on that library, not on Wickra. Wickra is not a trading system and is
+provided "as is" — see the disclaimers in `README.md` and the licenses.

SUPPORT.md

@@ -0,0 +1,37 @@
+# Support
+
+Thanks for using Wickra! Here is where to get help, depending on what you need.
+
+## Documentation first
+
+Most questions are answered in the documentation:
+
+- **Docs site:** <https://docs.wickra.org> — quickstarts for Rust, Python,
+  Node.js and WebAssembly, a per-indicator reference, warmup periods, the data
+  layer, and an FAQ.
+- **README:** <https://github.com/wickra-lib/wickra#readme> — installation and a
+  quick overview.
+- **API docs (Rust):** <https://docs.rs/wickra>.
+
+## Questions and help
+
+- Ask a question with the
+  [question issue template](.github/ISSUE_TEMPLATE/question.md).
+- Browse [existing issues](https://github.com/wickra-lib/wickra/issues) — your
+  question may already be answered.
+
+## Bugs and feature requests
+
+- **Bugs:** use the bug-report issue template.
+- **Feature requests / new indicators:** use the feature-request template.
+
+## Security issues
+
+Please do **not** report security vulnerabilities through public issues. Follow
+the process in [`SECURITY.md`](SECURITY.md) (private GitHub advisory or email).
+
+## Support expectations
+
+Wickra is maintained by a single maintainer on a best-effort basis. Issues are
+triaged and acknowledged as time allows; there is no commercial support or SLA.
+Clear, reproducible reports get help fastest.