feat(governance): Technical Steering Committee charter and founding roster

.specify/feature.json

@@ -1,3 +1,3 @@
 {
-  "feature_directory": "specs/016-openspec-migration"
+  "feature_directory": "specs/015-tsc-charter"
 }

CHARTER.md

@@ -0,0 +1,130 @@
+# darnit Technical Charter
+
+This Technical Charter (the "Charter") sets forth the responsibilities and procedures for technical contribution to, and oversight of, the darnit Project (the "Project").
+
+## 1. Mission and Scope of the Project
+
+The mission of the darnit Project is to provide an extensible, AI-assisted compliance auditing framework that separates a vendor-neutral core from pluggable compliance implementations, so that open source projects can be audited against multiple security and governance baselines (e.g., the OpenSSF Baseline) without re-implementing the auditing engine.
+
+The scope of the Project includes the framework, its first-party compliance implementations maintained in the same repository, and the tooling required to author, validate, and ship those implementations.
+
+## 2. Technical Steering Committee
+
+### 2.1 Composition
+
+The Project is governed by a Technical Steering Committee (the "TSC"). The TSC operates as a single-tier body: there is one TSC for the entire Project, regardless of the number of packages or implementations the Project ships.
+
+The current voting members of the TSC are listed in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md), with affiliation and industry-or-academia category disclosed for each member.
+
+The TSC has no fixed maximum size. Membership is not time-bounded -- members serve until resignation or removal under Section 2.5.
+
+### 2.2 Responsibilities
+
+The TSC is responsible for oversight of the Project, including:
+
+- Setting the Project's overall technical direction;
+- Approving Project releases and security policy;
+- Organizing, creating, and removing sub-projects or working groups;
+- Appointing representatives to other communities and foundations on the Project's behalf;
+- Establishing community norms, contribution workflows, and review processes;
+- Voting on cross-Project technical matters; and
+- Amending this Charter under Section 8.
+
+The TSC MAY delegate operational responsibilities -- such as day-to-day Pull Request review and release execution -- to maintainers under separate community documentation. Such delegation does not transfer the TSC's authority; the TSC remains the source of policy.
+
+### 2.3 Chair
+
+The TSC MAY elect a Chair from among its members. The Chair, if elected, presides over TSC discussions and serves as the Project's primary point of contact for foundation liaisons. The Chair serves until resignation or replacement by a subsequent TSC vote. The Project does not require a Chair to function; in the absence of a Chair, foundation liaison MAY be designated ad hoc by simple majority of the TSC for the matter at hand.
+
+### 2.4 Adding a Member
+
+A candidate for TSC membership is nominated by an existing TSC member. The nomination is recorded as a Pull Request that adds a row to [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md) populated with the candidate's name, affiliation, category, and GitHub handle.
+
+Existing TSC members vote on the nomination by approving or declining the Pull Request. The candidate is added to the TSC when a majority of the entire current TSC has approved the Pull Request, in accordance with Section 3 (TSC Voting). The merge commit is the canonical record of the decision.
+
+### 2.5 Removing a Member
+
+A TSC member MAY resign at any time by opening a Pull Request that removes their row from [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md). A resignation Pull Request does not require a vote; acknowledgment by another TSC member who merges the Pull Request suffices.
+
+A TSC member MAY be removed for cause -- including, but not limited to, inactivity or a serious violation of the Project's Code of Conduct -- by a vote of the *other* current TSC members. The member under review MUST NOT vote on their own removal. Removal for cause requires the approval of a majority of the other current TSC members, at the same level as ordinary TSC decisions.
+
+For the purposes of this Section, "inactivity" is not defined by a fixed numeric threshold (such as a specific number of months without contribution). Inactivity is a discretionary judgment by the remaining TSC members, initiated by a public GitHub Issue or Pull Request describing the basis for the proposed removal and resolved by the removal-for-cause threshold above.
+
+## 3. TSC Voting
+
+The TSC's goal is to operate as a consensus-based community. When a decision cannot be reached by consensus, the TSC MAY decide the matter by a vote conducted in accordance with this Section.
+
+### 3.1 General Voting Rules
+
+- Each TSC member has one vote.
+- Quorum for a vote is fifty percent (50%) of the current voting members of the TSC.
+- For a meeting or synchronous vote in which a quorum is present, a decision is approved by a simple majority of the members voting in favor versus against; abstentions do not count toward the total. Ties fail.
+- For decisions conducted electronically (e.g., on a Pull Request or GitHub Issue rather than in a meeting), a decision is approved when a majority of the entire TSC has voted in favor.
+- Amendments to this Charter (Section 8) and exceptions to the Project's stated license policy (Section 7) require the approval of at least two-thirds (2/3) of the entire TSC, not merely of those voting.
+
+### 3.2 Recording Votes
+
+Votes on decisions that modify a tracked file -- the roster, this Charter, or any other policy file in the repository -- are recorded by GitHub Pull Request approvals on the affected file. The Pull Request review state and the resulting merge commit constitute the canonical vote record.
+
+Votes on decisions that do not modify a file (for example, approving a representative to an external community, or endorsing an external statement on the Project's behalf) are recorded in a GitHub Issue or Discussion thread. Each TSC member casts a vote as an explicit comment of `+1`, `-1`, or `+0` on a single comment line, so that the tally is unambiguous to a casual reader and parseable by tooling. Subsequent artifacts that depend on the decision MUST link to the recording Issue or Discussion.
+
+### 3.3 Deadlocks
+
+If the TSC is unable to reach quorum, or to resolve a deadlock through ordinary voting under Section 3.1, the matter MAY be escalated to the LF Projects Series Manager once the Project is hosted under The Linux Foundation. Until such time as the Project is formally hosted, deadlocks are resolved by good-faith re-discussion among the TSC members.
+
+## 4. Compliance with Policies
+
+### 4.1 Code of Conduct
+
+The TSC and all Project contributors are subject to the Project's Code of Conduct, when adopted. Until the Project adopts a Code of Conduct of its own, the [LF Projects Code of Conduct](https://lfprojects.org/policies/code-of-conduct/) applies by default.
+
+### 4.2 Trademark and Antitrust
+
+The Project's name and any associated trademarks are the property of their respective holders. The TSC operates in compliance with applicable antitrust laws and avoids any discussion or action that would constitute unlawful coordination among competing organizations.
+
+### 4.3 Developer Certificate of Origin
+
+All contributions to the Project, including contributions to this Charter, MUST be signed off under the [Developer Certificate of Origin (DCO) version 1.1](https://developercertificate.org/).
+
+## 5. Community Assets
+
+The Project maintains the following community assets:
+
+- **Source repository**: <https://github.com/kusari-oss/darnit>
+- **Issues**: <https://github.com/kusari-oss/darnit/issues>
+- **Discussions**: <https://github.com/kusari-oss/darnit/discussions>
+- **Security reports**: see [SECURITY.md](./SECURITY.md)
+
+Additional assets -- for example, mailing lists, chat channels, or meeting venues -- MAY be added by TSC decision and announced through the Project's existing channels.
+
+## 6. General Rules and Operations
+
+The TSC will operate in a transparent, open, collaborative, and ethical manner at all times. The TSC will not seek to exclude any participant on any criteria other than those that are reasonable and applied on a non-discriminatory basis.
+
+All TSC meetings, when held, are open to the public. Decisions reached outside of meetings (for example, on Pull Requests or in Issues per Section 3.2) are public by virtue of the venue.
+
+TSC members are expected to disclose any conflicts of interest material to a decision before the TSC and to recuse themselves from decisions where their impartiality would be reasonably questioned.
+
+## 7. Intellectual Property Policy
+
+The Project ships the following classes of work under the following licenses:
+
+- **Source code** is licensed under the Apache License, version 2.0.
+- **Documentation**, including this Charter, is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0).
+- **Data** distributed by the Project is licensed under the Community Data License Agreement -- Permissive, version 2.0 (CDLA-Permissive-2.0).
+
+Contributions to the Project MUST be made under terms compatible with these licenses. Exceptions to the license stack require a vote of the TSC under Section 3.1 with the two-thirds threshold.
+
+## 8. Amendments
+
+This Charter MAY be amended by a Pull Request modifying this document, approved by at least two-thirds (2/3) of the entire TSC in accordance with Section 3.
+
+A proposed amendment SHOULD be announced through the Project's existing communication channels and allow a reasonable comment window before merge, so that the community has the opportunity to weigh in.
+
+---
+
+**Adopted**: 2026-06-17
+
+**Provenance**: Adapted from the LF Projects Technical Charter, also used by the [GUAC](https://github.com/guacsec/governance) and [gittuf](https://github.com/gittuf/community) projects.
+
+**License**: This document is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0).

CLAUDE.md

@@ -366,5 +366,5 @@ else:
 <!-- SPECKIT START -->
 For additional context about technologies to be used, project structure,
 shell commands, and other important information, read the current plan:
-[`specs/016-openspec-migration/plan.md`](specs/016-openspec-migration/plan.md)
+[`specs/015-tsc-charter/plan.md`](specs/015-tsc-charter/plan.md)
 <!-- SPECKIT END -->

GOVERNANCE.md

@@ -1,6 +1,8 @@
 # Governance
 
-This document describes the governance model for the darnit project.
+The darnit Project is governed by a Technical Steering Committee (TSC). The binding rules for membership, voting, and amendments live in the Project's [Charter](./CHARTER.md); the current voting members of the TSC are listed in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md).
+
+This document describes the operational layer below the Charter: how the Project is organized, what roles contributors fill, and how routine activities (PR review, releases) are run on a day-to-day basis. The Charter is the authority on governance decisions; this document is operational guidance and may be revised by maintainer consensus without a TSC vote.
 
 ## Project Structure
 
@@ -15,14 +17,16 @@ Future plugins can be developed as external packages following the plugin archit
 
 ## Roles and Responsibilities
 
+The TSC sets policy. The roles below operate under that policy and are responsible for day-to-day execution. TSC members are typically also maintainers, but the two roles are distinct: TSC authority comes from the [Charter](./CHARTER.md); maintainer authority comes from commit access granted by the TSC.
+
 ### Maintainers
 
 Maintainers have write access to the repository and are responsible for:
 
 - Reviewing and merging pull requests
 - Managing releases and versioning
 - Responding to security vulnerabilities
-- Setting project direction and priorities
+- Day-to-day technical direction within policy set by the TSC
 - Enforcing the Code of Conduct
 
 ### Contributors
@@ -42,21 +46,26 @@ A specialized contributor role for those who:
 - Implement sieve verification adapters
 - Write remediation functions
 
-## Decision Making
+## Day-to-Day PR Process
+
+The following thresholds apply to routine PR activity. Changes to *governance itself* -- this document, the [Charter](./CHARTER.md), or the [TSC roster](./TECHNICAL-STEERING-COMMITTEE.md) -- follow the TSC voting rules in the Charter instead.
 
 ### Minor Changes
+
 - Standard PR review and approval process
 - One maintainer approval required
 
 ### Major Changes
+
 - Open a GitHub Issue for discussion first
 - Allow community input before implementation
 - Document rationale in the PR
 
 ### Breaking Changes
+
 - Require RFC (Request for Comments) process
 - Minimum 7-day comment period
-- Requires consensus from maintainers
+- Approval by maintainer consensus
 
 ## Release Process
 
@@ -66,13 +75,14 @@ A specialized contributor role for those who:
 4. Automated PyPI publish via CI (when enabled)
 
 Releases follow [Semantic Versioning](https://semver.org/):
+
 - MAJOR: Breaking changes
 - MINOR: New features (backwards compatible)
 - PATCH: Bug fixes (backwards compatible)
 
 ## Code of Conduct
 
-All participants are expected to uphold a welcoming, harassment-free environment. Be respectful, constructive, and inclusive in all interactions.
+All participants are expected to uphold a welcoming, harassment-free environment. Be respectful, constructive, and inclusive in all interactions. The Project intends to adopt a project-specific Code of Conduct; until then, the LF Projects Code of Conduct applies per the [Charter](./CHARTER.md), Section 4.1.
 
 ## Contact
 

README.md

@@ -436,6 +436,10 @@ To report security vulnerabilities, see [SECURITY.md](SECURITY.md).
 
 For contributor setup and development workflow, see the [Getting Started Guide](GETTING_STARTED.md).
 
+## Governance
+
+The darnit Project is governed by a Technical Steering Committee (TSC). See the [Charter](CHARTER.md) for the binding governance rules, the [TSC roster](TECHNICAL-STEERING-COMMITTEE.md) for current voting members, and [GOVERNANCE.md](GOVERNANCE.md) for operational guidance (roles, release process, contact).
+
 ## License
 
 Apache-2.0

TECHNICAL-STEERING-COMMITTEE.md

@@ -0,0 +1,14 @@
+# Technical Steering Committee
+
+<!-- Adopted: 2026-06-17. License: CC-BY-4.0. -->
+
+The current voting members of the darnit Technical Steering Committee are:
+
+| Name | Affiliation | Category | GitHub | Role |
+|------|-------------|----------|--------|------|
+| Michael Lieberman | Kusari | industry | @mlieberman85 | member |
+| Justin Cappos | New York University | academia | @JustinCappos | member |
+| Stephen Augustus | Bloomberg | industry | @justaugustus | member |
+| Adolfo Garcia Veytia | Carabiner | industry | @puerco | member |
+
+For the rules that govern membership, voting, and amendments, see [CHARTER.md](./CHARTER.md).

specs/015-tsc-charter/checklists/requirements.md

@@ -0,0 +1,47 @@
+# Specification Quality Checklist: Technical Steering Committee Charter
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-06-17
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- Spec mirrors the LF Projects Technical Charter pattern used by both reference
+  projects (GUAC's two-tier structure was deliberately rejected in favor of
+  gittuf's single-tier; rationale captured in Assumptions).
+- The two-member founding roster creates a known transitional posture where
+  one member can carry a non-amendment vote. This is documented as an explicit
+  assumption rather than treated as a defect; recruiting a third member is
+  noted as a near-term action.
+- Three reasonable areas of judgment (charter location in-repo vs separate
+  governance repo, diversity-by-transparency vs hard employer quota, no fixed
+  terms / no required chair) were resolved by mirroring gittuf precedent and
+  documented in Assumptions, not raised as [NEEDS CLARIFICATION] questions,
+  consistent with the user's "real quick" framing.
+- No items remain incomplete; spec is ready for `/speckit-plan`. `/speckit-clarify`
+  is unnecessary unless the user wants to revisit any of the assumptions above.