dev-charter 0.0.1__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- dev_charter-0.0.1/.github/workflows/release.yml +62 -0
- dev_charter-0.0.1/.gitignore +8 -0
- dev_charter-0.0.1/LICENSE +201 -0
- dev_charter-0.0.1/NOTICE +9 -0
- dev_charter-0.0.1/PKG-INFO +227 -0
- dev_charter-0.0.1/README.md +207 -0
- dev_charter-0.0.1/docs/design/v0.1-plan.md +514 -0
- dev_charter-0.0.1/pyproject.toml +29 -0
- dev_charter-0.0.1/src/dev_charter/__init__.py +3 -0
- dev_charter-0.0.1/src/dev_charter/cli.py +17 -0
- dev_charter-0.0.1/uv.lock +23 -0
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Publishes Dev Charter to PyPI when a GitHub release is published.
|
|
2
|
+
# PyPI trusts this workflow by name (release.yml) and environment (pypi); no token is stored anywhere.
|
|
3
|
+
name: release
|
|
4
|
+
|
|
5
|
+
on:
|
|
6
|
+
release:
|
|
7
|
+
types: [published]
|
|
8
|
+
|
|
9
|
+
permissions: {}
|
|
10
|
+
|
|
11
|
+
jobs:
|
|
12
|
+
build:
|
|
13
|
+
runs-on: ubuntu-latest
|
|
14
|
+
permissions:
|
|
15
|
+
contents: read
|
|
16
|
+
steps:
|
|
17
|
+
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
|
18
|
+
with:
|
|
19
|
+
persist-credentials: false
|
|
20
|
+
- uses: astral-sh/setup-uv@07a047e608db84b3d8c06cd9a7c7dcc9c355c18e # v10.3.2
|
|
21
|
+
- name: Check the release tag matches the package version
|
|
22
|
+
run: |
|
|
23
|
+
version="$(uv version --short)"
|
|
24
|
+
if [ "v${version}" != "${GITHUB_REF_NAME}" ]; then
|
|
25
|
+
echo "The release tag ${GITHUB_REF_NAME} does not match the package version ${version}."
|
|
26
|
+
exit 1
|
|
27
|
+
fi
|
|
28
|
+
- run: uv build
|
|
29
|
+
- uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
|
|
30
|
+
with:
|
|
31
|
+
name: dist
|
|
32
|
+
path: dist/
|
|
33
|
+
|
|
34
|
+
publish:
|
|
35
|
+
needs: build
|
|
36
|
+
runs-on: ubuntu-latest
|
|
37
|
+
environment:
|
|
38
|
+
name: pypi
|
|
39
|
+
url: https://pypi.org/project/dev-charter/
|
|
40
|
+
permissions:
|
|
41
|
+
id-token: write
|
|
42
|
+
steps:
|
|
43
|
+
- uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
|
|
44
|
+
with:
|
|
45
|
+
name: dist
|
|
46
|
+
path: dist/
|
|
47
|
+
- uses: pypa/gh-action-pypi-publish@7245906fb61fa33a13554f9d5fb856fe61758086 # v1.14.3
|
|
48
|
+
|
|
49
|
+
attach:
|
|
50
|
+
needs: publish
|
|
51
|
+
runs-on: ubuntu-latest
|
|
52
|
+
permissions:
|
|
53
|
+
contents: write
|
|
54
|
+
steps:
|
|
55
|
+
- uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
|
|
56
|
+
with:
|
|
57
|
+
name: dist
|
|
58
|
+
path: dist/
|
|
59
|
+
- name: Attach the files to the GitHub release
|
|
60
|
+
env:
|
|
61
|
+
GH_TOKEN: ${{ github.token }}
|
|
62
|
+
run: gh release upload "${GITHUB_REF_NAME}" dist/* --repo "${GITHUB_REPOSITORY}"
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright [yyyy] [name of copyright owner]
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
dev_charter-0.0.1/NOTICE
ADDED
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
Dev Charter
|
|
2
|
+
Copyright 2026 Joji John
|
|
3
|
+
|
|
4
|
+
This product includes software developed by Joji John
|
|
5
|
+
(https://github.com/joji-opensource/charter).
|
|
6
|
+
|
|
7
|
+
Licensed under the Apache License, Version 2.0. See the LICENSE file for the
|
|
8
|
+
full terms. This NOTICE file provides attribution only; it does not modify or
|
|
9
|
+
add to the terms of the License.
|
|
@@ -0,0 +1,227 @@
|
|
|
1
|
+
Metadata-Version: 2.5
|
|
2
|
+
Name: dev-charter
|
|
3
|
+
Version: 0.0.1
|
|
4
|
+
Summary: Know what your product does, which code delivers it, and what is proven, in one spreadsheet.
|
|
5
|
+
Project-URL: Homepage, https://github.com/joji-opensource/charter
|
|
6
|
+
Project-URL: Issues, https://github.com/joji-opensource/charter/issues
|
|
7
|
+
Author: Joji John
|
|
8
|
+
License-Expression: Apache-2.0
|
|
9
|
+
License-File: LICENSE
|
|
10
|
+
License-File: NOTICE
|
|
11
|
+
Classifier: Development Status :: 1 - Planning
|
|
12
|
+
Classifier: Environment :: Console
|
|
13
|
+
Classifier: Intended Audience :: Developers
|
|
14
|
+
Classifier: Programming Language :: Python :: 3
|
|
15
|
+
Classifier: Programming Language :: Python :: 3 :: Only
|
|
16
|
+
Classifier: Topic :: Software Development :: Quality Assurance
|
|
17
|
+
Requires-Python: >=3.11
|
|
18
|
+
Requires-Dist: click<9,>=8.1
|
|
19
|
+
Description-Content-Type: text/markdown
|
|
20
|
+
|
|
21
|
+
# Dev Charter
|
|
22
|
+
|
|
23
|
+
**Know what your product does, which code delivers it, and what is proven — in one spreadsheet.**
|
|
24
|
+
|
|
25
|
+
Dev Charter keeps a plain-English record of every feature your product promises, links each one to the code that
|
|
26
|
+
builds it and the tests that prove it, and turns that into a spreadsheet a founder, product manager or executive
|
|
27
|
+
can read in five minutes. It is built for teams who write software with Claude Code, where code now arrives faster
|
|
28
|
+
than anyone can read it.
|
|
29
|
+
|
|
30
|
+
> **Status: early development.** The first working release is being built. Version 0.0.1 on PyPI only holds the
|
|
31
|
+
> name and does nothing yet; the commands below describe the first working release. Follow the repository to hear
|
|
32
|
+
> when it ships.
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## The problem
|
|
37
|
+
|
|
38
|
+
AI coding agents let a small team build a large product quickly. The cost shows up later:
|
|
39
|
+
|
|
40
|
+
- **Nobody can say what the product actually does today.** The code is there, but the answer to "can a customer
|
|
41
|
+
do X yet, and how do we know?" takes a day of reading or an engineer's opinion.
|
|
42
|
+
- **Code grows that no one can explain.** Tens of thousands of lines appear, and no one can point to which
|
|
43
|
+
customer need each part serves, or whether any of it is still needed.
|
|
44
|
+
- **Plans pile up as documents.** Designs, reviews and decision notes multiply until they are longer than the code
|
|
45
|
+
and too long to read.
|
|
46
|
+
- **"Done" means "the agent said so."** Status is claimed, not proven, and it goes stale the moment the next
|
|
47
|
+
change lands.
|
|
48
|
+
- **Scope drifts quietly.** Each "while I'm here" improvement looks reasonable on its own; together they build a
|
|
49
|
+
different product than the one you planned.
|
|
50
|
+
|
|
51
|
+
## What you get
|
|
52
|
+
|
|
53
|
+
### For founders and product owners
|
|
54
|
+
|
|
55
|
+
- **One page that answers "where are we?"** Every feature, in plain English, with its status, in a spreadsheet at
|
|
56
|
+
the root of your project. No technical knowledge needed to read it.
|
|
57
|
+
- **Features written the way customers think.** Each one reads *"As a customer, I want to … with … so that …"*,
|
|
58
|
+
followed by what "done" means in plain words. You review the product, not the code.
|
|
59
|
+
- **Status you can trust.** A feature only moves to *Built* when its checks pass, and only to *Proven* when a named
|
|
60
|
+
person has seen it work on real data and signed it off. Status is never typed in: it is worked out from the
|
|
61
|
+
checks and the sign-offs, and every sign-off records who and when.
|
|
62
|
+
- **Early warning.** A feature that used to work and now fails is flagged *At risk* the next time the
|
|
63
|
+
spreadsheet is generated, before a customer finds it.
|
|
64
|
+
- **Control over what gets built.** Every piece of work names the feature it serves. Ideas that don't serve an
|
|
65
|
+
agreed feature are captured in one list for you to decide on later, instead of quietly becoming code.
|
|
66
|
+
|
|
67
|
+
### For executives, investors and customers
|
|
68
|
+
|
|
69
|
+
- **A summary you can share.** Features by area and status, the share that is proven, and what changed this week.
|
|
70
|
+
- **Claims backed by evidence.** Every "this works" points to the checks behind it and the date it was last
|
|
71
|
+
proven.
|
|
72
|
+
- **Release readiness at a glance.** See which features in a release are proven, which are built but unproven, and
|
|
73
|
+
which haven't started.
|
|
74
|
+
|
|
75
|
+
### For engineers and AI coding agents
|
|
76
|
+
|
|
77
|
+
- **Every task is tied to a customer need.** The agent knows which feature and which checks its work serves, and
|
|
78
|
+
what is out of bounds.
|
|
79
|
+
- **Code that explains itself.** Each module carries a short tag naming the feature it serves. The *Code map* shows
|
|
80
|
+
every module, the features behind it, and the code that serves nothing: candidates to justify or remove.
|
|
81
|
+
- **Decisions made once.** One decisions log, plain-English summary first, so settled questions are not reopened
|
|
82
|
+
in every session.
|
|
83
|
+
- **Clean handoffs.** Each session ends with where it stopped and the exact next step, so the next session, or the
|
|
84
|
+
next person, starts without guessing.
|
|
85
|
+
|
|
86
|
+
### Before and after
|
|
87
|
+
|
|
88
|
+
| Question | Without Dev Charter | With Dev Charter |
|
|
89
|
+
|---|---|---|
|
|
90
|
+
| Is this feature done? | Ask someone, get an opinion | Open the spreadsheet: calculated status and last proven date |
|
|
91
|
+
| Why does this code exist? | Read it, or guess | The *Code map* names the feature it serves |
|
|
92
|
+
| What code serves nothing? | Nobody knows | Listed as *Unexplained code* |
|
|
93
|
+
| What did we decide, and why? | Spread across chats and documents | One decisions log |
|
|
94
|
+
| What changed this week? | A status report someone writes by hand | Generated after every commit |
|
|
95
|
+
| Did the agent stay on task? | Find out in code review | Work that serves no feature is flagged before you commit |
|
|
96
|
+
|
|
97
|
+
## What a feature looks like
|
|
98
|
+
|
|
99
|
+
```
|
|
100
|
+
F-014 · Area: Orders and delivery · Priority: Must · Release: Spring launch
|
|
101
|
+
|
|
102
|
+
As a customer of an online store
|
|
103
|
+
I want to see where my order is and when it will arrive
|
|
104
|
+
With the current step (packed, shipped, out for delivery), the expected delivery date,
|
|
105
|
+
and a text message when it is out for delivery
|
|
106
|
+
Must also load in under 2 seconds on a phone · show me only my own orders
|
|
107
|
+
So that I don't have to contact support to ask where my package is
|
|
108
|
+
|
|
109
|
+
Done means
|
|
110
|
+
a. Every order shows its current step and expected delivery date
|
|
111
|
+
b. A text message is sent when the order goes out for delivery
|
|
112
|
+
c. Opening someone else's order shows a sign-in page, never their order
|
|
113
|
+
|
|
114
|
+
Status Built: 2 of 3 checks passing (calculated)
|
|
115
|
+
Built in Orders service · Notifications (found in the code)
|
|
116
|
+
Proven by 7 automated checks · last real run 24 Oct
|
|
117
|
+
Decisions DEC-031 (delivery dates come from the carrier, never guessed)
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
You write the top half, or ask your agent to. Dev Charter fills in the bottom half from the code and the test results.
|
|
121
|
+
|
|
122
|
+
**Statuses:** Idea → Agreed → Being built → Built → Proven → Live, plus *At risk*, *Parked* and *Retired*.
|
|
123
|
+
|
|
124
|
+
**Promises** are product-wide rules that apply to many features, such as *"customers only ever see their own
|
|
125
|
+
orders and details"* or *"the price shown is always the price charged"*. They get their own rows and their own
|
|
126
|
+
checks.
|
|
127
|
+
|
|
128
|
+
## How it works
|
|
129
|
+
|
|
130
|
+
Dev Charter has three layers. You can use the first two on their own.
|
|
131
|
+
|
|
132
|
+
1. **The Ledger: what and why.** One short text file per feature, promise and decision, kept in your repository.
|
|
133
|
+
People and agents write these.
|
|
134
|
+
2. **The Trace: where and how do we know.** A one-line tag in each module (`serves: F-014`) and the feature's ID in
|
|
135
|
+
each test's name (`test_F014_b_text_sent`) link code and tests back to features. Dev Charter scans your
|
|
136
|
+
repositories, in any language, and reads test results in JUnit XML, which pytest and most test runners write
|
|
137
|
+
(Jest and Go through a small add-on).
|
|
138
|
+
3. **The Workflow: how the agent works.** Task cards that name the feature they serve, a plan → review → prove →
|
|
139
|
+
build → ship loop, one list for parked ideas, and a handoff at the end of each session.
|
|
140
|
+
|
|
141
|
+
`dev-charter report` combines all three into `LEDGER.xlsx` and a one-page `status.html`. They are rebuilt after every
|
|
142
|
+
commit, on demand, and in CI, and never edited by hand, so they cannot drift from the truth.
|
|
143
|
+
|
|
144
|
+
### Built for Claude Code
|
|
145
|
+
|
|
146
|
+
Dev Charter's rules live in your repository, in `AGENTS.md`, which Claude Code reads every time it opens the project,
|
|
147
|
+
so every teammate's sessions follow them. The full guide for each stage comes from the installed Dev Charter
|
|
148
|
+
(`dev-charter guide plan`), so every project gets the same guides and upgrading Dev Charter upgrades them everywhere. The
|
|
149
|
+
Dev Charter plugin adds commands such as `/dev-charter:feature` and `/dev-charter:plan`, and Strict mode.
|
|
150
|
+
|
|
151
|
+
Other AI coding tools that read `AGENTS.md` are planned for a later release; this release is tested with Claude
|
|
152
|
+
Code only.
|
|
153
|
+
|
|
154
|
+
### The spreadsheet
|
|
155
|
+
|
|
156
|
+
| Tab | What it shows |
|
|
157
|
+
|---|---|
|
|
158
|
+
| Summary | Features by area and status, share proven, what changed this week |
|
|
159
|
+
| Features | One row per feature, the main view |
|
|
160
|
+
| Promises | Product-wide rules and their status |
|
|
161
|
+
| Code map | Each module and the features it serves; unexplained code flagged |
|
|
162
|
+
| Decisions | Every decision, plain English first |
|
|
163
|
+
| Ideas | Everything parked for later |
|
|
164
|
+
|
|
165
|
+
## Choose how strict to be
|
|
166
|
+
|
|
167
|
+
| Mode | When Dev Charter checks | Best for |
|
|
168
|
+
|---|---|---|
|
|
169
|
+
| **Light** | In CI, after work is merged | Prototypes, adding Dev Charter to an existing project gradually, teams without AI agents |
|
|
170
|
+
| **Standard** | Before each commit | Everyday work where a person reviews and commits |
|
|
171
|
+
| **Strict** | At every file change: Claude Code is blocked from writing outside its task | Long unattended agent runs, several agents at once, shared core code |
|
|
172
|
+
|
|
173
|
+
Switch modes with one line in `charter.toml`, or turn on Strict for a single session.
|
|
174
|
+
|
|
175
|
+
## Getting started
|
|
176
|
+
|
|
177
|
+
**1. Install Dev Charter** (once per machine, in a terminal):
|
|
178
|
+
|
|
179
|
+
```bash
|
|
180
|
+
uv tool install dev-charter
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
**2. Add the Dev Charter plugin** (once per machine, inside Claude Code):
|
|
184
|
+
|
|
185
|
+
```
|
|
186
|
+
/plugin marketplace add joji-opensource/charter
|
|
187
|
+
/plugin install dev-charter@dev-charter
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
**3. Set up your project** (open Claude Code in your project folder):
|
|
191
|
+
|
|
192
|
+
```
|
|
193
|
+
/dev-charter:init
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
Claude asks five questions (product name, repositories, product areas, user roles, how strict to be) and sets
|
|
197
|
+
everything up. Prefer the terminal? `dev-charter init` asks the same questions.
|
|
198
|
+
|
|
199
|
+
**4. Work**
|
|
200
|
+
|
|
201
|
+
```
|
|
202
|
+
/dev-charter:feature As a customer I want to save products for later …
|
|
203
|
+
/dev-charter:status where are we?
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
`LEDGER.xlsx` and `status.html` are rebuilt after every commit; `dev-charter report` rebuilds them any time.
|
|
207
|
+
|
|
208
|
+
`/dev-charter:init` adds only your product's own content to your project: a `charter.toml` settings file, a `charter/`
|
|
209
|
+
folder with your features, promises, decisions, ideas, task cards and handoff, a short marked section in
|
|
210
|
+
`AGENTS.md`, and git hooks that check each commit and refresh the spreadsheet. It never overwrites a hook you
|
|
211
|
+
already have. Framework code never lives in your repository; upgrading Dev Charter upgrades every project that uses
|
|
212
|
+
it.
|
|
213
|
+
|
|
214
|
+
## What Dev Charter is not
|
|
215
|
+
|
|
216
|
+
- **Not a task tracker.** It does not replace Jira, Linear or ClickUp for scheduling work. It records what the
|
|
217
|
+
product promises and whether each promise is kept.
|
|
218
|
+
- **Not a test framework.** It reads the results of the tests you already run.
|
|
219
|
+
- **Not tied to a language, stack or cloud.** Anything that can carry a comment and produce JUnit XML works.
|
|
220
|
+
|
|
221
|
+
## License
|
|
222
|
+
|
|
223
|
+
Apache License 2.0. See [LICENSE](https://github.com/joji-opensource/charter/blob/main/LICENSE) and
|
|
224
|
+
[NOTICE](https://github.com/joji-opensource/charter/blob/main/NOTICE).
|
|
225
|
+
|
|
226
|
+
If you redistribute Dev Charter or a modified version, keep the LICENSE file, the copyright notices and the NOTICE
|
|
227
|
+
file, as the License requires.
|
|
@@ -0,0 +1,207 @@
|
|
|
1
|
+
# Dev Charter
|
|
2
|
+
|
|
3
|
+
**Know what your product does, which code delivers it, and what is proven — in one spreadsheet.**
|
|
4
|
+
|
|
5
|
+
Dev Charter keeps a plain-English record of every feature your product promises, links each one to the code that
|
|
6
|
+
builds it and the tests that prove it, and turns that into a spreadsheet a founder, product manager or executive
|
|
7
|
+
can read in five minutes. It is built for teams who write software with Claude Code, where code now arrives faster
|
|
8
|
+
than anyone can read it.
|
|
9
|
+
|
|
10
|
+
> **Status: early development.** The first working release is being built. Version 0.0.1 on PyPI only holds the
|
|
11
|
+
> name and does nothing yet; the commands below describe the first working release. Follow the repository to hear
|
|
12
|
+
> when it ships.
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
## The problem
|
|
17
|
+
|
|
18
|
+
AI coding agents let a small team build a large product quickly. The cost shows up later:
|
|
19
|
+
|
|
20
|
+
- **Nobody can say what the product actually does today.** The code is there, but the answer to "can a customer
|
|
21
|
+
do X yet, and how do we know?" takes a day of reading or an engineer's opinion.
|
|
22
|
+
- **Code grows that no one can explain.** Tens of thousands of lines appear, and no one can point to which
|
|
23
|
+
customer need each part serves, or whether any of it is still needed.
|
|
24
|
+
- **Plans pile up as documents.** Designs, reviews and decision notes multiply until they are longer than the code
|
|
25
|
+
and too long to read.
|
|
26
|
+
- **"Done" means "the agent said so."** Status is claimed, not proven, and it goes stale the moment the next
|
|
27
|
+
change lands.
|
|
28
|
+
- **Scope drifts quietly.** Each "while I'm here" improvement looks reasonable on its own; together they build a
|
|
29
|
+
different product than the one you planned.
|
|
30
|
+
|
|
31
|
+
## What you get
|
|
32
|
+
|
|
33
|
+
### For founders and product owners
|
|
34
|
+
|
|
35
|
+
- **One page that answers "where are we?"** Every feature, in plain English, with its status, in a spreadsheet at
|
|
36
|
+
the root of your project. No technical knowledge needed to read it.
|
|
37
|
+
- **Features written the way customers think.** Each one reads *"As a customer, I want to … with … so that …"*,
|
|
38
|
+
followed by what "done" means in plain words. You review the product, not the code.
|
|
39
|
+
- **Status you can trust.** A feature only moves to *Built* when its checks pass, and only to *Proven* when a named
|
|
40
|
+
person has seen it work on real data and signed it off. Status is never typed in: it is worked out from the
|
|
41
|
+
checks and the sign-offs, and every sign-off records who and when.
|
|
42
|
+
- **Early warning.** A feature that used to work and now fails is flagged *At risk* the next time the
|
|
43
|
+
spreadsheet is generated, before a customer finds it.
|
|
44
|
+
- **Control over what gets built.** Every piece of work names the feature it serves. Ideas that don't serve an
|
|
45
|
+
agreed feature are captured in one list for you to decide on later, instead of quietly becoming code.
|
|
46
|
+
|
|
47
|
+
### For executives, investors and customers
|
|
48
|
+
|
|
49
|
+
- **A summary you can share.** Features by area and status, the share that is proven, and what changed this week.
|
|
50
|
+
- **Claims backed by evidence.** Every "this works" points to the checks behind it and the date it was last
|
|
51
|
+
proven.
|
|
52
|
+
- **Release readiness at a glance.** See which features in a release are proven, which are built but unproven, and
|
|
53
|
+
which haven't started.
|
|
54
|
+
|
|
55
|
+
### For engineers and AI coding agents
|
|
56
|
+
|
|
57
|
+
- **Every task is tied to a customer need.** The agent knows which feature and which checks its work serves, and
|
|
58
|
+
what is out of bounds.
|
|
59
|
+
- **Code that explains itself.** Each module carries a short tag naming the feature it serves. The *Code map* shows
|
|
60
|
+
every module, the features behind it, and the code that serves nothing: candidates to justify or remove.
|
|
61
|
+
- **Decisions made once.** One decisions log, plain-English summary first, so settled questions are not reopened
|
|
62
|
+
in every session.
|
|
63
|
+
- **Clean handoffs.** Each session ends with where it stopped and the exact next step, so the next session, or the
|
|
64
|
+
next person, starts without guessing.
|
|
65
|
+
|
|
66
|
+
### Before and after
|
|
67
|
+
|
|
68
|
+
| Question | Without Dev Charter | With Dev Charter |
|
|
69
|
+
|---|---|---|
|
|
70
|
+
| Is this feature done? | Ask someone, get an opinion | Open the spreadsheet: calculated status and last proven date |
|
|
71
|
+
| Why does this code exist? | Read it, or guess | The *Code map* names the feature it serves |
|
|
72
|
+
| What code serves nothing? | Nobody knows | Listed as *Unexplained code* |
|
|
73
|
+
| What did we decide, and why? | Spread across chats and documents | One decisions log |
|
|
74
|
+
| What changed this week? | A status report someone writes by hand | Generated after every commit |
|
|
75
|
+
| Did the agent stay on task? | Find out in code review | Work that serves no feature is flagged before you commit |
|
|
76
|
+
|
|
77
|
+
## What a feature looks like
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
F-014 · Area: Orders and delivery · Priority: Must · Release: Spring launch
|
|
81
|
+
|
|
82
|
+
As a customer of an online store
|
|
83
|
+
I want to see where my order is and when it will arrive
|
|
84
|
+
With the current step (packed, shipped, out for delivery), the expected delivery date,
|
|
85
|
+
and a text message when it is out for delivery
|
|
86
|
+
Must also load in under 2 seconds on a phone · show me only my own orders
|
|
87
|
+
So that I don't have to contact support to ask where my package is
|
|
88
|
+
|
|
89
|
+
Done means
|
|
90
|
+
a. Every order shows its current step and expected delivery date
|
|
91
|
+
b. A text message is sent when the order goes out for delivery
|
|
92
|
+
c. Opening someone else's order shows a sign-in page, never their order
|
|
93
|
+
|
|
94
|
+
Status Built: 2 of 3 checks passing (calculated)
|
|
95
|
+
Built in Orders service · Notifications (found in the code)
|
|
96
|
+
Proven by 7 automated checks · last real run 24 Oct
|
|
97
|
+
Decisions DEC-031 (delivery dates come from the carrier, never guessed)
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
You write the top half, or ask your agent to. Dev Charter fills in the bottom half from the code and the test results.
|
|
101
|
+
|
|
102
|
+
**Statuses:** Idea → Agreed → Being built → Built → Proven → Live, plus *At risk*, *Parked* and *Retired*.
|
|
103
|
+
|
|
104
|
+
**Promises** are product-wide rules that apply to many features, such as *"customers only ever see their own
|
|
105
|
+
orders and details"* or *"the price shown is always the price charged"*. They get their own rows and their own
|
|
106
|
+
checks.
|
|
107
|
+
|
|
108
|
+
## How it works
|
|
109
|
+
|
|
110
|
+
Dev Charter has three layers. You can use the first two on their own.
|
|
111
|
+
|
|
112
|
+
1. **The Ledger: what and why.** One short text file per feature, promise and decision, kept in your repository.
|
|
113
|
+
People and agents write these.
|
|
114
|
+
2. **The Trace: where and how do we know.** A one-line tag in each module (`serves: F-014`) and the feature's ID in
|
|
115
|
+
each test's name (`test_F014_b_text_sent`) link code and tests back to features. Dev Charter scans your
|
|
116
|
+
repositories, in any language, and reads test results in JUnit XML, which pytest and most test runners write
|
|
117
|
+
(Jest and Go through a small add-on).
|
|
118
|
+
3. **The Workflow: how the agent works.** Task cards that name the feature they serve, a plan → review → prove →
|
|
119
|
+
build → ship loop, one list for parked ideas, and a handoff at the end of each session.
|
|
120
|
+
|
|
121
|
+
`dev-charter report` combines all three into `LEDGER.xlsx` and a one-page `status.html`. They are rebuilt after every
|
|
122
|
+
commit, on demand, and in CI, and never edited by hand, so they cannot drift from the truth.
|
|
123
|
+
|
|
124
|
+
### Built for Claude Code
|
|
125
|
+
|
|
126
|
+
Dev Charter's rules live in your repository, in `AGENTS.md`, which Claude Code reads every time it opens the project,
|
|
127
|
+
so every teammate's sessions follow them. The full guide for each stage comes from the installed Dev Charter
|
|
128
|
+
(`dev-charter guide plan`), so every project gets the same guides and upgrading Dev Charter upgrades them everywhere. The
|
|
129
|
+
Dev Charter plugin adds commands such as `/dev-charter:feature` and `/dev-charter:plan`, and Strict mode.
|
|
130
|
+
|
|
131
|
+
Other AI coding tools that read `AGENTS.md` are planned for a later release; this release is tested with Claude
|
|
132
|
+
Code only.
|
|
133
|
+
|
|
134
|
+
### The spreadsheet
|
|
135
|
+
|
|
136
|
+
| Tab | What it shows |
|
|
137
|
+
|---|---|
|
|
138
|
+
| Summary | Features by area and status, share proven, what changed this week |
|
|
139
|
+
| Features | One row per feature, the main view |
|
|
140
|
+
| Promises | Product-wide rules and their status |
|
|
141
|
+
| Code map | Each module and the features it serves; unexplained code flagged |
|
|
142
|
+
| Decisions | Every decision, plain English first |
|
|
143
|
+
| Ideas | Everything parked for later |
|
|
144
|
+
|
|
145
|
+
## Choose how strict to be
|
|
146
|
+
|
|
147
|
+
| Mode | When Dev Charter checks | Best for |
|
|
148
|
+
|---|---|---|
|
|
149
|
+
| **Light** | In CI, after work is merged | Prototypes, adding Dev Charter to an existing project gradually, teams without AI agents |
|
|
150
|
+
| **Standard** | Before each commit | Everyday work where a person reviews and commits |
|
|
151
|
+
| **Strict** | At every file change: Claude Code is blocked from writing outside its task | Long unattended agent runs, several agents at once, shared core code |
|
|
152
|
+
|
|
153
|
+
Switch modes with one line in `charter.toml`, or turn on Strict for a single session.
|
|
154
|
+
|
|
155
|
+
## Getting started
|
|
156
|
+
|
|
157
|
+
**1. Install Dev Charter** (once per machine, in a terminal):
|
|
158
|
+
|
|
159
|
+
```bash
|
|
160
|
+
uv tool install dev-charter
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
**2. Add the Dev Charter plugin** (once per machine, inside Claude Code):
|
|
164
|
+
|
|
165
|
+
```
|
|
166
|
+
/plugin marketplace add joji-opensource/charter
|
|
167
|
+
/plugin install dev-charter@dev-charter
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
**3. Set up your project** (open Claude Code in your project folder):
|
|
171
|
+
|
|
172
|
+
```
|
|
173
|
+
/dev-charter:init
|
|
174
|
+
```
|
|
175
|
+
|
|
176
|
+
Claude asks five questions (product name, repositories, product areas, user roles, how strict to be) and sets
|
|
177
|
+
everything up. Prefer the terminal? `dev-charter init` asks the same questions.
|
|
178
|
+
|
|
179
|
+
**4. Work**
|
|
180
|
+
|
|
181
|
+
```
|
|
182
|
+
/dev-charter:feature As a customer I want to save products for later …
|
|
183
|
+
/dev-charter:status where are we?
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
`LEDGER.xlsx` and `status.html` are rebuilt after every commit; `dev-charter report` rebuilds them any time.
|
|
187
|
+
|
|
188
|
+
`/dev-charter:init` adds only your product's own content to your project: a `charter.toml` settings file, a `charter/`
|
|
189
|
+
folder with your features, promises, decisions, ideas, task cards and handoff, a short marked section in
|
|
190
|
+
`AGENTS.md`, and git hooks that check each commit and refresh the spreadsheet. It never overwrites a hook you
|
|
191
|
+
already have. Framework code never lives in your repository; upgrading Dev Charter upgrades every project that uses
|
|
192
|
+
it.
|
|
193
|
+
|
|
194
|
+
## What Dev Charter is not
|
|
195
|
+
|
|
196
|
+
- **Not a task tracker.** It does not replace Jira, Linear or ClickUp for scheduling work. It records what the
|
|
197
|
+
product promises and whether each promise is kept.
|
|
198
|
+
- **Not a test framework.** It reads the results of the tests you already run.
|
|
199
|
+
- **Not tied to a language, stack or cloud.** Anything that can carry a comment and produce JUnit XML works.
|
|
200
|
+
|
|
201
|
+
## License
|
|
202
|
+
|
|
203
|
+
Apache License 2.0. See [LICENSE](https://github.com/joji-opensource/charter/blob/main/LICENSE) and
|
|
204
|
+
[NOTICE](https://github.com/joji-opensource/charter/blob/main/NOTICE).
|
|
205
|
+
|
|
206
|
+
If you redistribute Dev Charter or a modified version, keep the LICENSE file, the copyright notices and the NOTICE
|
|
207
|
+
file, as the License requires.
|
|
@@ -0,0 +1,514 @@
|
|
|
1
|
+
# Dev Charter v0.1 — build plan
|
|
2
|
+
|
|
3
|
+
version: draft 4 (after review ×2 and probe rounds 1 and 2; v0.1 focused on Claude Code)
|
|
4
|
+
date: 2026-10-25
|
|
5
|
+
|
|
6
|
+
The plan for Dev Charter's first release. It follows Dev Charter's own loop: plan → review ×2 → probe → build. The body is
|
|
7
|
+
always the plan of record; the review log (§9) and the probe results (§10) record what changed it and why.
|
|
8
|
+
|
|
9
|
+
## 1. Goal
|
|
10
|
+
|
|
11
|
+
A product team installs Dev Charter in an existing or new repository and, the same day, has:
|
|
12
|
+
|
|
13
|
+
- a plain-English feature list in their repository, readable by anyone;
|
|
14
|
+
- a generated spreadsheet that shows every feature, the code that builds it, the tests that prove it, and a status
|
|
15
|
+
worked out from those tests and from people's sign-offs;
|
|
16
|
+
- Claude Code following Dev Charter's way of working, with no setup beyond installing Dev Charter and its plugin.
|
|
17
|
+
|
|
18
|
+
v0.1 is built and tested for Claude Code only (Joji, 2026-10-25). Nothing in it is specific to Claude Code where it
|
|
19
|
+
does not need to be: the rules live in `AGENTS.md` and the checks run in git, so other coding tools can follow in a
|
|
20
|
+
later release.
|
|
21
|
+
|
|
22
|
+
## 2. Requirements
|
|
23
|
+
|
|
24
|
+
- **R-01 Install like a customer.** `uv tool install dev-charter` (or `uv tool install git+https://github.com/joji-opensource/charter`
|
|
25
|
+
before PyPI) gives a `dev-charter` command, with the stage guides inside it. *Done when:* a clean machine installs it
|
|
26
|
+
and `dev-charter guide plan` prints the packaged guide. (Proven for the git form: P6.)
|
|
27
|
+
- **R-02 Set up any repository.** `dev-charter init` works in a single repository and in a root that holds several
|
|
28
|
+
repositories, nested or side by side. *Done when:* it writes `charter.toml`, the `charter/` folder, the agent
|
|
29
|
+
instructions (R-06), the git hooks (§5.7) and the `.gitignore` entries; running it twice changes nothing.
|
|
30
|
+
- **R-03 Features, promises, decisions, ideas as files.** One Markdown file per feature, promise and decision; one
|
|
31
|
+
ideas file. `dev-charter feature new` hands out the next ID and writes the full template. *Done when:* a file written
|
|
32
|
+
by a person or an agent from the template is read back without loss, and a malformed file produces a
|
|
33
|
+
plain-English error naming the file and line.
|
|
34
|
+
- **R-04 The spreadsheet.** `dev-charter report` writes `LEDGER.xlsx` (Summary, Features, Promises, Code map,
|
|
35
|
+
Decisions, Ideas) and `status.html`. Dev Charter sets every row height itself (P2). *Done when:* a person opens the
|
|
36
|
+
demo store's file in Excel, Numbers and Google Sheets and finds it readable: wrapped text, coloured statuses,
|
|
37
|
+
frozen header row.
|
|
38
|
+
- **R-05 Trace and calculated status.** Tags and test names as in §5.3, test results from JUnit XML, status by the
|
|
39
|
+
rules in §5.4. *Done when:* on the demo store, turning one test from passing to failing turns its feature from
|
|
40
|
+
Proven to At risk in the next report (shown in miniature by P3b).
|
|
41
|
+
- **R-06 Instructions in the repository.** After `dev-charter init`, Claude Code opened in the repository knows
|
|
42
|
+
Dev Charter's rules and loads the full guide for each stage with `dev-charter guide <stage>`, even for a teammate who has
|
|
43
|
+
not installed the plugin. Delivered through `AGENTS.md`, which Claude Code loads by itself. *Done when:* Claude
|
|
44
|
+
Code, started fresh in the demo store and asked to plan a change without being told about Dev Charter, runs
|
|
45
|
+
`dev-charter guide plan` and follows it. (Proven: P1, P1b.)
|
|
46
|
+
- **R-07 Checks.** `dev-charter check` validates files and the trace (§5.6). Runs in CI in every mode and before each
|
|
47
|
+
commit in Standard and Strict.
|
|
48
|
+
- **R-08 Modes.** Light, Standard, Strict, set in `charter.toml`; Strict can be turned on for one session.
|
|
49
|
+
- **R-09 Claude Code plugin.** Part of the standard install. `/dev-charter:init` asks the setup questions in
|
|
50
|
+
conversation and runs `dev-charter init`; `/dev-charter:feature` turns a plain-English request into a feature through
|
|
51
|
+
`dev-charter feature new`; one skill per stage (`/dev-charter:plan`, `/dev-charter:review`, …) loads that stage's guide;
|
|
52
|
+
`/dev-charter:status` and `/dev-charter:park`; the session starts with `dev-charter status --brief`; the Strict-mode edit
|
|
53
|
+
guard. Rules never live only in the plugin: they are in `AGENTS.md` (R-06), so the plugin adds shortcuts and
|
|
54
|
+
Strict mode, not knowledge. Each skill declares `allowed-tools` for exactly the `dev-charter` commands it runs
|
|
55
|
+
(`Bash(dev-charter guide:*)`, `Bash(dev-charter feature new:*)`, …), never wider, so a person is not asked for permission
|
|
56
|
+
at every step (P9).
|
|
57
|
+
|
|
58
|
+
## 3. Non-goals for v0.1
|
|
59
|
+
|
|
60
|
+
- **N-01** Two-way sync from the spreadsheet back to the files (`dev-charter import` is later).
|
|
61
|
+
- **N-02** Mapping existing code to features automatically. v0.1 lists untagged code so a person or agent can tag
|
|
62
|
+
it; the mapping skill is v0.2.
|
|
63
|
+
- **N-03** Hosting, accounts, a web app. Dev Charter is files plus a command.
|
|
64
|
+
- **N-04** Task scheduling (dates, assignees, sprints).
|
|
65
|
+
- **N-05** Coding tools other than Claude Code (Codex, GitHub Copilot, Cursor and others): not tested, documented or
|
|
66
|
+
supported in v0.1. Nothing is done to exclude them either.
|
|
67
|
+
|
|
68
|
+
## 4. Package layout
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
charter/ repository root
|
|
72
|
+
LICENSE NOTICE README.md
|
|
73
|
+
pyproject.toml name "dev-charter", Python ≥3.11, script `dev-charter = dev_charter.cli:main`, hatchling
|
|
74
|
+
dependencies: click, pyyaml, openpyxl, packaging
|
|
75
|
+
src/dev_charter/
|
|
76
|
+
__init__.py __version__
|
|
77
|
+
cli.py click group; each command is a thin wrapper over the modules below
|
|
78
|
+
config.py load and validate charter.toml; find the root by walking up to it
|
|
79
|
+
model.py Feature, Criterion, Promise, Decision, Idea, Card, SignOff
|
|
80
|
+
store.py read and write the files in charter/; hand out the next ID
|
|
81
|
+
scan.py per repo, `git ls-files --cached --others --exclude-standard` (a plain walk when
|
|
82
|
+
the folder is not a git repository); finds code tags and test IDs (§5.3)
|
|
83
|
+
results.py reads JUnit XML; maps each test case to IDs by its name
|
|
84
|
+
status.py the rules in §5.4; pure functions over model, scan and results
|
|
85
|
+
report/xlsx.py the spreadsheet; sets row heights from text length and column width
|
|
86
|
+
report/html.py status.html, one self-contained page, standard library only
|
|
87
|
+
check.py the rules in §5.6; findings carry file and line
|
|
88
|
+
agents.py writes and refreshes the managed block in AGENTS.md (§5.5)
|
|
89
|
+
hooks.py installs the git hooks (§5.7)
|
|
90
|
+
guides/ principles, feature, plan, review, probe, build, verify, ship
|
|
91
|
+
templates/ feature.md, promise.md, decision.md, card.md, handoff.md, charter.toml,
|
|
92
|
+
agents_block.md
|
|
93
|
+
plugin/ the Claude Code plugin; nothing in it reaches outside plugin/
|
|
94
|
+
.claude-plugin/plugin.json
|
|
95
|
+
skills/init/SKILL.md asks the setup questions, then runs `dev-charter init` with every answer as a flag
|
|
96
|
+
skills/feature/SKILL.md turns a request into a feature through `dev-charter feature new`
|
|
97
|
+
skills/<stage>/SKILL.md plan, review, probe, build, verify, ship: each runs `dev-charter guide <stage>`
|
|
98
|
+
skills/status, skills/park run `dev-charter status` and `dev-charter park`
|
|
99
|
+
hooks/hooks.json {"hooks": {...}}: SessionStart → `dev-charter status --brief`;
|
|
100
|
+
PreToolUse on Edit|Write → `dev-charter guard` (acts only in Strict)
|
|
101
|
+
.claude-plugin/marketplace.json name "dev-charter", with a description; plugin source "./plugin"
|
|
102
|
+
docs/ guide for product owners; guide for contributors
|
|
103
|
+
examples/demo-store/ the online-store demo used by the README and the tests
|
|
104
|
+
tests/
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Every source file starts with `# Copyright 2026 Joji John` and `# SPDX-License-Identifier: Apache-2.0`.
|
|
108
|
+
|
|
109
|
+
## 5. Contracts
|
|
110
|
+
|
|
111
|
+
### 5.1 `charter.toml`
|
|
112
|
+
|
|
113
|
+
```toml
|
|
114
|
+
[product]
|
|
115
|
+
name = "Demo Store"
|
|
116
|
+
mode = "standard" # light | standard | strict
|
|
117
|
+
dev-charter = ">=0.1,<0.2" # Dev Charter versions this project works with; checked on every command
|
|
118
|
+
|
|
119
|
+
[[repos]]
|
|
120
|
+
path = "." # relative to this file; one entry per repository
|
|
121
|
+
results = ["reports/junit/*.xml"] # where that repo's test runner writes JUnit XML
|
|
122
|
+
# code = ["src/**"] # optional; defaults: common source extensions outside test folders
|
|
123
|
+
# tests = ["tests/**"] # optional; defaults: tests/, test_*.*, *_test.*, *.test.*, *.spec.*
|
|
124
|
+
|
|
125
|
+
[words]
|
|
126
|
+
roles = ["customer", "store admin", "support agent"]
|
|
127
|
+
areas = ["Orders and delivery", "Checkout", "Accounts"]
|
|
128
|
+
internal = [] # jargon that must not appear in plain-English text
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
### 5.2 Files in `charter/`
|
|
132
|
+
|
|
133
|
+
```
|
|
134
|
+
charter/
|
|
135
|
+
features/F-014-track-my-order.md
|
|
136
|
+
promises/P-002-only-see-your-own-orders.md
|
|
137
|
+
decisions/DEC-031-delivery-dates-from-carrier.md
|
|
138
|
+
ideas.md
|
|
139
|
+
cards/CARD-007-order-status-page.md
|
|
140
|
+
handoff.md
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
A feature file. The labels are fixed; a label's text runs until the next label or a blank line.
|
|
144
|
+
|
|
145
|
+
```markdown
|
|
146
|
+
---
|
|
147
|
+
id: F-014
|
|
148
|
+
title: Track my order
|
|
149
|
+
area: Orders and delivery
|
|
150
|
+
priority: Must # Must | Should | Could
|
|
151
|
+
release: Spring launch
|
|
152
|
+
state: agreed # idea | agreed | live | parked | retired — set by people only
|
|
153
|
+
decisions: [DEC-031]
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
**As a** customer of an online store
|
|
157
|
+
**I want to** see where my order is and when it will arrive
|
|
158
|
+
**With** the current step (packed, shipped, out for delivery), the expected delivery date, and a text message
|
|
159
|
+
when it is out for delivery
|
|
160
|
+
**Must also** load in under 2 seconds on a phone · show me only my own orders
|
|
161
|
+
**So that** I don't have to contact support to ask where my package is
|
|
162
|
+
|
|
163
|
+
## Done means
|
|
164
|
+
|
|
165
|
+
- **a.** Every order shows its current step and expected delivery date
|
|
166
|
+
- **b.** A text message is sent when the order goes out for delivery
|
|
167
|
+
- **c.** Opening someone else's order shows a sign-in page, never their order
|
|
168
|
+
|
|
169
|
+
## Sign-offs
|
|
170
|
+
|
|
171
|
+
- 2026-10-24 · b · Joji John · received the text on a real phone during a staging order
|
|
172
|
+
- 2026-10-24 · proven · Joji John · watched the whole flow work on staging with a real order
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
A sign-off line is `date · <criterion letter or "proven"> · <person> · <what they saw>`. A criterion sign-off covers
|
|
176
|
+
checks that are not automated (a text arriving on a phone, a page loading fast enough on a real device).
|
|
177
|
+
|
|
178
|
+
`ideas.md` is one bullet per idea: `- 2026-10-25 · <idea> · from <card, feature or person>`. A decision file has
|
|
179
|
+
frontmatter `id`, `date`, `decided_by`, then **Decision**, **Instead of**, **Because**. A card has frontmatter
|
|
180
|
+
`id`, `serves` (criterion IDs), `state`, then **Goal**, **Plan**, **Done when**, and in Strict mode **Allowed
|
|
181
|
+
paths**. `handoff.md` holds only the latest state: done with evidence, in progress, parked, exact next step.
|
|
182
|
+
|
|
183
|
+
### 5.3 Tags
|
|
184
|
+
|
|
185
|
+
- **IDs** are `F-` or `P-` followed by three or more digits (`F-014`, `P-002`), with a criterion letter after a dot
|
|
186
|
+
(`F-014.b`). Decisions are `DEC-nnn`, cards `CARD-nnn`.
|
|
187
|
+
- **Code.** A comment containing `serves:` followed by IDs: `# serves: F-014, P-002`. Only a `serves:` line with
|
|
188
|
+
at least one well-formed ID counts (P4 found `serves:` in ordinary prose). Shared code that every feature relies
|
|
189
|
+
on says `serves: foundation`; it is shown as *Shared foundation*, not as unexplained.
|
|
190
|
+
- **Tests.** The criterion ID inside the test's name, in whatever form the language allows: `test_F014_b_text_sent`,
|
|
191
|
+
`it("F-014.b sends a text")`, `func TestF014B(t *testing.T)`. Matched with
|
|
192
|
+
`(?<![A-Za-z0-9])([FP])-?(\d{3,})(?:[._-]?([a-zA-Z]))?(?![A-Za-z0-9])`; the prefix letter must be upper case and
|
|
193
|
+
any parameter part in brackets is removed first (P3). IDs are looked for only on `serves:` lines and in test
|
|
194
|
+
names, never elsewhere in code (P4 found linter codes such as `F401` and colours such as `f800`).
|
|
195
|
+
- **Results.** JUnit XML, the default format of each runner (pytest needs no option: P3). A test case's IDs come from
|
|
196
|
+
its name; its outcome from its `failure`, `error` and `skipped` children.
|
|
197
|
+
|
|
198
|
+
### 5.4 Status rules
|
|
199
|
+
|
|
200
|
+
Each criterion is:
|
|
201
|
+
|
|
202
|
+
- **failing** if any test tagged with it failed or errored in the latest results;
|
|
203
|
+
- otherwise **passing** if at least one tagged test passed, or a person signed it off;
|
|
204
|
+
- otherwise **unchecked**. Skipped tests count for nothing.
|
|
205
|
+
|
|
206
|
+
Then, per feature, the first rule that matches wins:
|
|
207
|
+
|
|
208
|
+
1. `state` is idea, parked or retired → that state.
|
|
209
|
+
2. Any criterion is failing and the feature is `live` or has a `proven` sign-off → **At risk**.
|
|
210
|
+
3. `state: live` → **Live**.
|
|
211
|
+
4. Every criterion is passing and there is a `proven` sign-off → **Proven**.
|
|
212
|
+
5. Every criterion is passing → **Built**.
|
|
213
|
+
6. Any code or test is tagged with the feature → **Being built**.
|
|
214
|
+
7. Otherwise → **Agreed**.
|
|
215
|
+
|
|
216
|
+
Every status shows its count beside it (*2 of 3 checks passing*), so a Live or Proven feature that gained a new,
|
|
217
|
+
unchecked criterion says so. Each repo's results show the time they were written; `dev-charter check` warns when a
|
|
218
|
+
repo's results are older than its latest commit.
|
|
219
|
+
|
|
220
|
+
### 5.5 Agent instructions
|
|
221
|
+
|
|
222
|
+
- `dev-charter init` writes a managed block, between `<!-- dev-charter:start v<version> -->` and `<!-- dev-charter:end -->`,
|
|
223
|
+
into `AGENTS.md`, creating the file if needed and never touching text outside the block. At most 40 lines: what
|
|
224
|
+
Dev Charter is here, the rules below, and the commands.
|
|
225
|
+
- The rules: every change serves a feature or promise; run `dev-charter status --brief` before starting work; load
|
|
226
|
+
`dev-charter guide <stage>` before each stage; add features with `dev-charter feature new` (never invent an ID); tag new
|
|
227
|
+
code and name tests with criterion IDs; park ideas with `dev-charter park`; run `dev-charter check` before saying work is
|
|
228
|
+
done; never write a sign-off, never set `state`, never commit with `--no-verify`.
|
|
229
|
+
- `CLAUDE.md` is not touched: Claude Code loads `AGENTS.md` on its own (P1, P1b).
|
|
230
|
+
- `dev-charter sync` refreshes the block after an upgrade; `dev-charter check` warns when the block's version differs from
|
|
231
|
+
the installed Dev Charter.
|
|
232
|
+
- The full guides live in the installed package (`dev-charter guide <stage>`), so every project gets the same guides
|
|
233
|
+
and upgrading Dev Charter upgrades them everywhere.
|
|
234
|
+
- The `feature` guide requires the agent to list, in its reply, any criterion the person did not ask for, so the
|
|
235
|
+
person keeps or removes it (P5).
|
|
236
|
+
|
|
237
|
+
### 5.6 What `dev-charter check` checks
|
|
238
|
+
|
|
239
|
+
| Finding | Light (CI) | Standard / Strict (before commit) |
|
|
240
|
+
|---|---|---|
|
|
241
|
+
| Malformed file, duplicate ID, unknown ID on a `serves:` line | error | error |
|
|
242
|
+
| A new code file with no `serves:` tag | warning | error |
|
|
243
|
+
| A changed code file with no `serves:` tag | warning | warning |
|
|
244
|
+
| An unknown ID in a test name | warning | warning |
|
|
245
|
+
| A word from `[words] internal` in plain-English text | warning | warning |
|
|
246
|
+
| A feature file over 250 words | warning | warning |
|
|
247
|
+
| Stale results, out-of-date instruction block, a repo without the commit check | warning | warning |
|
|
248
|
+
|
|
249
|
+
`dev-charter check --staged` looks only at what is about to be committed.
|
|
250
|
+
|
|
251
|
+
### 5.7 When things run
|
|
252
|
+
|
|
253
|
+
- **Before each commit** (Standard and Strict): a git `pre-commit` hook runs `dev-charter check --staged`.
|
|
254
|
+
- **After each commit** (every mode): a git `post-commit` hook runs `dev-charter report --quiet`, so the spreadsheet on
|
|
255
|
+
each machine is never older than the last commit. The scan takes under a second on 170,000 lines (P4).
|
|
256
|
+
- **In CI:** `dev-charter check` and `dev-charter report`; the spreadsheet is attached to each release.
|
|
257
|
+
- **On demand:** `dev-charter report`, `dev-charter status`.
|
|
258
|
+
- **Claude Code plugin:** `SessionStart` prints `dev-charter status --brief` into the session; in Strict mode,
|
|
259
|
+
`PreToolUse` on Edit and Write denies writes outside the active card's allowed paths and any edit that adds a
|
|
260
|
+
sign-off line. Nothing runs on `Stop` or `SessionEnd` (Stop fires after every turn; SessionEnd has 1.5 seconds).
|
|
261
|
+
|
|
262
|
+
Hook installation, in each repository listed in `charter.toml`: the hooks folder is the one
|
|
263
|
+
`git rev-parse --git-path hooks` names, which honours `core.hooksPath` (P8). If a hook of the same name already
|
|
264
|
+
exists, or the repo uses the pre-commit framework, Dev Charter does not overwrite it: it prints the one line to add.
|
|
265
|
+
Each hook calls `dev-charter … --root <relative path to the charter root>` and, when `dev-charter` is not installed,
|
|
266
|
+
prints one line saying so and lets the commit through.
|
|
267
|
+
|
|
268
|
+
## 6. Stages, each with something to see
|
|
269
|
+
|
|
270
|
+
1. **Ledger and instructions.** `init`, `feature new`, `guide`, `report` (Summary, Features, Promises, Decisions,
|
|
271
|
+
Ideas), the `AGENTS.md` block. *You see:* `LEDGER.xlsx` for the demo store, and a fresh Claude Code session in
|
|
272
|
+
the demo store following Dev Charter unprompted.
|
|
273
|
+
2. **Trace and status.** `scan`, results, status rules, the Code map tab, `check`, git hooks. *You see:* a test
|
|
274
|
+
turned red turns a feature At risk; a commit with an untagged new file is stopped with a plain-English reason.
|
|
275
|
+
3. **Claude Code plugin.** `/dev-charter:init`, `/dev-charter:feature`, the stage skills, session-start status, Strict
|
|
276
|
+
guard. *You see:* a new project set up by answering questions in Claude Code, and a Strict session refused an
|
|
277
|
+
edit outside its card.
|
|
278
|
+
4. **Release.** CI workflow, PyPI release. *You see:* `uv tool install dev-charter` from PyPI.
|
|
279
|
+
|
|
280
|
+
## 6a. Packaging and distribution
|
|
281
|
+
|
|
282
|
+
### What ships, and where
|
|
283
|
+
|
|
284
|
+
| Piece | Published to | People get it with | People update with |
|
|
285
|
+
|---|---|---|---|
|
|
286
|
+
| The `dev-charter` command, with its guides and templates | PyPI, project `dev-charter` | `uv tool install dev-charter` | `uv tool upgrade dev-charter` |
|
|
287
|
+
| The Claude Code plugin | this GitHub repository, which is also its marketplace | `/plugin marketplace add joji-opensource/charter`, then `/plugin install dev-charter@dev-charter` | `/plugin update dev-charter@dev-charter`, then restart |
|
|
288
|
+
| Release notes, wheel and source archive | GitHub Releases | — | — |
|
|
289
|
+
|
|
290
|
+
Later, once v0.1 is stable: submit the plugin to Anthropic's plugin directory (`claude plugin validate --profile
|
|
291
|
+
directory`; the directory adds a safety scan and a policy review).
|
|
292
|
+
|
|
293
|
+
### One version number
|
|
294
|
+
|
|
295
|
+
- `pyproject.toml`'s version, `plugin/.claude-plugin/plugin.json`'s version and the git tag `vX.Y.Z` are the same
|
|
296
|
+
number; the release workflow stops if they differ. The command and the plugin are always released together.
|
|
297
|
+
- The plugin's session-start hook compares `dev-charter --version` with its own version and, when they differ, says in
|
|
298
|
+
one plain line which one to update.
|
|
299
|
+
- A project's `charter.toml` names the Dev Charter versions it works with; every command checks it.
|
|
300
|
+
- Semantic versioning. While 0.x, a minor release may change behaviour, always with a note in `CHANGELOG.md`.
|
|
301
|
+
|
|
302
|
+
### Branches
|
|
303
|
+
|
|
304
|
+
`main` holds only released code; work happens on `dev`; a release merges `dev` into `main` and tags it. Reason:
|
|
305
|
+
people who add the plugin get it from the repository's default branch, so unreleased plugin changes on `main` would
|
|
306
|
+
reach them before the matching command is on PyPI. (Assumption: the marketplace follows the default branch. To be
|
|
307
|
+
probed in stage 3 by installing from GitHub.)
|
|
308
|
+
|
|
309
|
+
### Release pipeline (GitHub Actions)
|
|
310
|
+
|
|
311
|
+
- **`ci.yml`, on every push and pull request:** `uv sync --locked`; ruff; pytest on Python 3.11 to 3.13 on Linux and
|
|
312
|
+
macOS; `uv build`; `twine check`; `claude plugin validate .` and `claude plugin validate ./plugin`; the three
|
|
313
|
+
version numbers agree.
|
|
314
|
+
- **`release.yml`, on a `v*` tag:** build once and keep the files; wait in the `pypi` environment for Joji's
|
|
315
|
+
approval; publish with PyPI trusted publishing (no stored token) and its signed attestations; create the GitHub
|
|
316
|
+
Release with notes and files.
|
|
317
|
+
- Actions pinned to commit hashes; Dependabot keeps the actions and `uv.lock` current.
|
|
318
|
+
|
|
319
|
+
### What every package contains
|
|
320
|
+
|
|
321
|
+
`LICENSE` and `NOTICE` (declared with `license-files`; P10), the README as the PyPI page with absolute links, the
|
|
322
|
+
guides and templates as package data, and the copyright header in every source file.
|
|
323
|
+
|
|
324
|
+
### The name
|
|
325
|
+
|
|
326
|
+
The framework was first named Charter. PyPI refused `charter` in the pending-publisher form ("This project name isn't
|
|
327
|
+
allowed"): no existing project collides with it, so it is on PyPI's own list of disallowed names. The word is also
|
|
328
|
+
crowded in this exact space (`charter-intent`, "executable design intent for AI-coded repos"; `project-charter`, an
|
|
329
|
+
AI agent governance engine; `charter-governance`; and `charter-cli`, which already installs a `charter` command).
|
|
330
|
+
Renamed **Dev Charter** (Joji, 2026-10-25): `dev-charter` is free on PyPI and TestPyPI, with no look-alike name.
|
|
331
|
+
|
|
332
|
+
| Where | Name |
|
|
333
|
+
|---|---|
|
|
334
|
+
| Brand in prose | Dev Charter |
|
|
335
|
+
| PyPI project and command | `dev-charter` |
|
|
336
|
+
| Claude Code plugin and marketplace | `dev-charter` (`/dev-charter:feature`, `/plugin install dev-charter@dev-charter`) |
|
|
337
|
+
| Python package | `dev_charter` |
|
|
338
|
+
| GitHub repository | `joji-opensource/charter`, unchanged: the PyPI publisher trusts that exact name |
|
|
339
|
+
| In a customer's project | `charter/` and `charter.toml`: the product's charter, the document Dev Charter keeps |
|
|
340
|
+
|
|
341
|
+
Renaming the repository later means updating the trusted publisher on PyPI in the same step.
|
|
342
|
+
|
|
343
|
+
### Registering the name
|
|
344
|
+
|
|
345
|
+
PyPI cannot reserve a name: the project exists from its first upload, and a pending trusted publisher does not hold
|
|
346
|
+
the name. The first release is therefore a small, honest 0.0.1 that doubles as the rehearsal of the pipeline:
|
|
347
|
+
`dev-charter --version` and a message pointing to the repository, marked *Development Status :: 1 - Planning*, with
|
|
348
|
+
the README as its page.
|
|
349
|
+
|
|
350
|
+
Steps only Joji can do:
|
|
351
|
+
|
|
352
|
+
1. ~~Create a PyPI account with two-factor sign-in.~~ Done.
|
|
353
|
+
2. ~~Add a pending publisher on PyPI: project `dev-charter`, owner `joji-opensource`, repository `charter`, workflow
|
|
354
|
+
`release.yml`, environment `pypi`.~~ Done, 2026-10-25.
|
|
355
|
+
3. On GitHub, *charter → Settings → Environments → New environment* `pypi`, with yourself as required reviewer, so
|
|
356
|
+
every release waits for your approval.
|
|
357
|
+
4. Commit and push the 0.0.1 files, then publish a GitHub release tagged `v0.0.1`, and approve the run.
|
|
358
|
+
|
|
359
|
+
## 7. Load-bearing assumptions
|
|
360
|
+
|
|
361
|
+
| # | Assumption | Probe | Result |
|
|
362
|
+
|---|---|---|---|
|
|
363
|
+
| A1 | Claude Code started fresh picks up the rules from `AGENTS.md` and runs `dev-charter guide` | P1, P1b | PASS (loads it with no tools) |
|
|
364
|
+
| A2 | An openpyxl spreadsheet with long wrapped cells is readable | P2 | PARTIAL: Dev Charter must set row heights; Excel, Numbers, Google Sheets need a person |
|
|
365
|
+
| A3 | Test names in JUnit XML carry enough to map tests to criteria, and §5.4 gives the right status | P3, P3b | PASS, with parameter stripping |
|
|
366
|
+
| A4 | A text scan finds tags fast and without false matches | P4, P4b | FAIL, then PASS after two rule fixes |
|
|
367
|
+
| A5 | An agent-written feature file parses without loss | P5 | PASS |
|
|
368
|
+
| A6 | The package installs from a git address with its guides inside | P6 | PASS |
|
|
369
|
+
| A7 | The plugin and marketplace layout is valid | P7 | PASS, one warning fixed |
|
|
370
|
+
| A8 | Git hooks can be installed without breaking existing setups | P8 | PASS, with no-overwrite rule |
|
|
371
|
+
| A9 | A plugin skill can run its `dev-charter` commands without a permission prompt | P9 | PASS, with `allowed-tools` per skill |
|
|
372
|
+
| A10 | The built package carries LICENSE and NOTICE and passes PyPI's checks | P10 | PASS |
|
|
373
|
+
| A11 | A plugin added from GitHub follows the repository's default branch | stage 3 | not yet probed |
|
|
374
|
+
|
|
375
|
+
## 8. Open decisions for Joji
|
|
376
|
+
|
|
377
|
+
- None open. Publishing 0.0.1 was decided 2026-10-25 (§6a); it is public, and the name stays claimed even if the
|
|
378
|
+
release is later removed.
|
|
379
|
+
|
|
380
|
+
## 9. Review log
|
|
381
|
+
|
|
382
|
+
### Pass 1 (on draft 1)
|
|
383
|
+
|
|
384
|
+
Problems first; each fix is in the body above.
|
|
385
|
+
|
|
386
|
+
1. **Instructions only reached Claude Code** (draft 1 §5.5 wrote `CLAUDE.md`), contradicting R-06. → `AGENTS.md`
|
|
387
|
+
managed block; `CLAUDE.md` untouched; guides served by `dev-charter guide`.
|
|
388
|
+
2. **"After every session" depended on Claude Code's `Stop` hook**, which fires after every turn, and other tools
|
|
389
|
+
have no such hook. → git `post-commit` rebuilds the spreadsheet; `pre-commit` runs the check. Works with every
|
|
390
|
+
tool and with people.
|
|
391
|
+
3. **Non-automatable criteria could never pass** (a text arriving on a phone, speed on a real device). → criterion
|
|
392
|
+
sign-offs (§5.2) count as passing.
|
|
393
|
+
4. **Skipped tests, stale results and Live features with gaps were undefined.** → §5.4: skipped counts for nothing;
|
|
394
|
+
results show their time and stale ones warn; every status shows its check count.
|
|
395
|
+
5. **Shared code had no honest tag**, so it would be flagged unexplained forever or tagged with a random feature. →
|
|
396
|
+
`serves: foundation`.
|
|
397
|
+
6. **An existing codebase would fail every commit** if untagged changed files were errors. → only new untagged files
|
|
398
|
+
stop a commit; changed ones warn.
|
|
399
|
+
7. **Duplicate IDs from parallel branches** were not caught. → `dev-charter check` error; `feature new` hands out IDs.
|
|
400
|
+
8. **Which files are code and which are tests** was not defined. → defaults plus optional globs per repo (§5.1).
|
|
401
|
+
9. **Scanning by `.gitignore` rules would skip nested repositories** (a parent repo usually ignores its children). →
|
|
402
|
+
`git ls-files` per listed repository.
|
|
403
|
+
10. **Over-engineering check:** separate promise and feature parsers → one model with a kind; Jinja for one HTML page
|
|
404
|
+
→ standard library; plugin skills duplicating guide text → skills call `dev-charter guide`.
|
|
405
|
+
11. **README over-claimed:** "neither you nor the agent can simply declare it done", "rebuilt after every agent
|
|
406
|
+
session", `/feature` for a plugin skill, "any test runner that writes JUnit XML" without saying some need an
|
|
407
|
+
add-on, Strict without saying it needs Claude Code. → README corrected.
|
|
408
|
+
|
|
409
|
+
### Pass 2 (on draft 2)
|
|
410
|
+
|
|
411
|
+
Smaller and not structural; fixed in the body.
|
|
412
|
+
|
|
413
|
+
1. A git hook in a child repository must find the charter root. → hooks carry `--root`.
|
|
414
|
+
2. A teammate without Dev Charter installed must still be able to commit. → hooks let the commit through with one line.
|
|
415
|
+
3. `serves: foundation` could become a dumping ground. → the Summary tab shows its share of the code.
|
|
416
|
+
4. Three-digit IDs cap a product at 999 features. → three or more digits.
|
|
417
|
+
5. R-06 is now core, so the instruction block moved from stage 3 to stage 1.
|
|
418
|
+
6. Agents can skip hooks with `git commit --no-verify`. → forbidden in the instruction block; CI catches what slips.
|
|
419
|
+
|
|
420
|
+
Stopped reviewing: pass 2 found no structural gap.
|
|
421
|
+
|
|
422
|
+
## 10. Probe results
|
|
423
|
+
|
|
424
|
+
Probe code is scratch and is not kept in this repository; each result below is the fact it produced. The probes ran
|
|
425
|
+
before the rename to Dev Charter; commands are shown under today's name.
|
|
426
|
+
|
|
427
|
+
### Round 1
|
|
428
|
+
|
|
429
|
+
**P1 — instructions through `AGENTS.md` (Claude Code 2.1.310).** *Method:* a fresh git repo with only an
|
|
430
|
+
`AGENTS.md` block telling the agent to run `dev-charter guide plan` before planning; a stand-in `dev-charter` on PATH whose
|
|
431
|
+
guide demands a marker line; prompt "Plan how to add a wishlist so customers can save products for later. Don't
|
|
432
|
+
write any code." (Dev Charter not mentioned). Two layouts: `AGENTS.md` alone, and `CLAUDE.md` containing `@AGENTS.md`.
|
|
433
|
+
*Verdict:* **PASS** for both. Each session ran `dev-charter guide plan`, began with the marker, said the work needed a
|
|
434
|
+
new feature, and declined to set a status. *Also found:* the agent guessed the next ID itself and copied the format
|
|
435
|
+
of the existing (minimal) feature file. *What changes:* `dev-charter feature new` hands out IDs and writes the full
|
|
436
|
+
template; the block forbids inventing IDs. *Not run:* Codex (its command-line tool is installed but its program file
|
|
437
|
+
is missing), GitHub Copilot (command-line tool not installed), Cursor (no command-line agent installed). Since
|
|
438
|
+
draft 4 these tools are outside v0.1 (N-05).
|
|
439
|
+
|
|
440
|
+
**P2 — spreadsheet readability.** *Method:* openpyxl workbook with four demo features and long multi-line cells,
|
|
441
|
+
row heights left to the viewer (A) or set by Dev Charter (B), rendered with macOS Quick Look. *Verdict:* **PARTIAL.**
|
|
442
|
+
B renders as designed; A's heights depend on the viewer. Quick Look shows only the top-left of the sheet, so Excel,
|
|
443
|
+
Numbers and Google Sheets need a person. *What changes:* Dev Charter always sets row heights; R-04's done-when is a
|
|
444
|
+
person's check.
|
|
445
|
+
|
|
446
|
+
**P3 — test names in JUnit XML.** *Method:* a real 129-test pytest suite run with `--junitxml`, default format and
|
|
447
|
+
`junit_family=xunit1`. *Verdict:* **PASS.** The default format carries `classname` and `name`, not file or line;
|
|
448
|
+
parameterised tests carry their parameters in brackets (`test_x[schema/connection_type.schema.json]`). *What
|
|
449
|
+
changes:* match IDs on the name, after removing the bracketed part; no runner option needed.
|
|
450
|
+
|
|
451
|
+
**P4 — tag scan on a real multi-repository product.** *Method:* `git ls-files` plus regular expressions across 12
|
|
452
|
+
repositories. *Verdict:* **PASS on speed, FAIL on precision.** 930 source files, 170,682 lines, 0.68 seconds. The
|
|
453
|
+
draft rules matched `serves:` in an ordinary docstring, and the case-insensitive ID pattern matched linter codes
|
|
454
|
+
(`F401`) and colour values (`f800`) 20 times. *What changes:* §5.3 — `serves:` counts only with a well-formed ID;
|
|
455
|
+
upper-case prefix; IDs looked for only on `serves:` lines and in test names.
|
|
456
|
+
|
|
457
|
+
**P6 — install from a git address.** *Method:* minimal package (hatchling, click, a guide file inside the package),
|
|
458
|
+
installed with `uvx --from git+file://…` and run as `dev-charter guide plan`. *Verdict:* **PASS.** The guide file is
|
|
459
|
+
packaged without extra configuration and read through `importlib.resources`.
|
|
460
|
+
|
|
461
|
+
**P7 — plugin layout.** *Method:* `claude plugin validate .` and `claude plugin validate ./plugin` on a marketplace
|
|
462
|
+
at the root pointing at `./plugin`. *Verdict:* **PASS** with one warning: the marketplace needs a description.
|
|
463
|
+
*What changes:* description added (§4). The documentation also says plugin skills are called as
|
|
464
|
+
`/dev-charter:<skill>` and install is `/plugin install dev-charter@dev-charter` (marketplace name `dev-charter`).
|
|
465
|
+
|
|
466
|
+
**P8 — git hooks next to existing setups.** *Method:* three repos (none, an existing pre-commit hook, husky's
|
|
467
|
+
`core.hooksPath`) plus the real multi-repo root. *Verdict:* **PASS.** `git rev-parse --git-path hooks` names the
|
|
468
|
+
right folder in each case; the real root and its child repos have no hooks yet. *What changes:* never overwrite an
|
|
469
|
+
existing hook; print the line to add instead.
|
|
470
|
+
|
|
471
|
+
### Round 2 (re-testing the fixes)
|
|
472
|
+
|
|
473
|
+
**P4b — the corrected tag rules on the same codebase.** *Verdict:* **PASS.** 930 files in 0.32 seconds; zero false
|
|
474
|
+
tags, zero false test IDs; the one `serves:` in prose is ignored.
|
|
475
|
+
|
|
476
|
+
**P3b — status end to end on real pytest results.** *Method:* a demo store with three features in the §5.2 format
|
|
477
|
+
(one with a criterion sign-off and a `proven` sign-off), two tagged modules, tests named with criterion IDs, a
|
|
478
|
+
skipped test, and a decoy parameter `F-150-truck`; pytest run to JUnit XML twice, all green and then with F-014.c
|
|
479
|
+
failing. *Verdict:* **PASS.** All green: F-014 *Proven (3 of 3)* (criterion b passing by sign-off), F-013 *Being
|
|
480
|
+
built (2 of 3)* (skipped test counted for nothing), F-016 *Agreed*. With F-014.c red: F-014 *At risk (2 of 3)*. The
|
|
481
|
+
decoy parameter was not read as an ID; the multi-line **With** label parsed whole.
|
|
482
|
+
|
|
483
|
+
**P1b — does Claude Code load `AGENTS.md` itself?** *Method:* asked, with every tool disabled, what the repository's
|
|
484
|
+
instructions say about sign-offs and guides; control: the same question in a folder without `AGENTS.md`.
|
|
485
|
+
*Verdict:* **PASS.** It quoted both rules from `AGENTS.md`; the control answered `NONE`. *What changes:* `CLAUDE.md`
|
|
486
|
+
is not needed (§5.5).
|
|
487
|
+
|
|
488
|
+
**P5 — an agent fills in a feature.** *Method:* Claude Code given the §5.2 template as a placeholder file and the
|
|
489
|
+
request "customers want to save products to a wishlist so they can buy them later, and only they can see their
|
|
490
|
+
list"; the result parsed with the P3b parser. *Verdict:* **PASS.** Every label and all five criteria read back; no
|
|
491
|
+
sign-off written; `state` left alone; the area chosen from the allowed list. *Also found:* the agent added two
|
|
492
|
+
criteria beyond the request and said so. *What changes:* the `feature` guide makes that a rule: any criterion the
|
|
493
|
+
person did not ask for is listed in the reply for them to keep or remove.
|
|
494
|
+
|
|
495
|
+
### Round 3 (after the Claude Code focus)
|
|
496
|
+
|
|
497
|
+
**P9 — plugin skills without permission prompts.** *Method:* the same plugin loaded with `--plugin-dir` in two
|
|
498
|
+
copies of a fresh repo with no `AGENTS.md`, run as `/dev-charter:plan …` in non-interactive mode (where any command
|
|
499
|
+
that is not allowed is refused): one skill declaring `allowed-tools: Bash(dev-charter guide:*)`, one without.
|
|
500
|
+
*Verdict:* **PASS.** With the declaration the skill ran `dev-charter guide plan` and followed the guide; without it the
|
|
501
|
+
command was refused and the agent said it could not load the guide. *What changes:* every skill declares exactly
|
|
502
|
+
the `dev-charter` commands it runs (R-09).
|
|
503
|
+
|
|
504
|
+
**P10 — what the built package contains.** *Method:* `uv build` of the minimal package with the real `LICENSE`,
|
|
505
|
+
`NOTICE` and README and `license-files = ["LICENSE", "NOTICE"]`; wheel and source archive listed; `twine check`.
|
|
506
|
+
*Verdict:* **PASS.** Both files are in the wheel (`dist-info/licenses/`) and the source archive; metadata 2.5 with
|
|
507
|
+
`License-Expression: Apache-2.0`; the packaged guide is present; `twine check` passes. *Also found:* the README's
|
|
508
|
+
relative links would break on the PyPI page, so they are now absolute; and `charter` was free on PyPI's index but
|
|
509
|
+
taken on TestPyPI. (PyPI later refused `charter` outright, which led to the rename in §6a.)
|
|
510
|
+
|
|
511
|
+
### Still open
|
|
512
|
+
|
|
513
|
+
- R-04's readability in Excel, Numbers and Google Sheets (a person opens the file).
|
|
514
|
+
- A11, the plugin's update path from GitHub (stage 3).
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
[project]
|
|
2
|
+
name = "dev-charter"
|
|
3
|
+
version = "0.0.1"
|
|
4
|
+
description = "Know what your product does, which code delivers it, and what is proven, in one spreadsheet."
|
|
5
|
+
readme = "README.md"
|
|
6
|
+
license = "Apache-2.0"
|
|
7
|
+
license-files = ["LICENSE", "NOTICE"]
|
|
8
|
+
authors = [{ name = "Joji John" }]
|
|
9
|
+
requires-python = ">=3.11"
|
|
10
|
+
dependencies = ["click>=8.1,<9"]
|
|
11
|
+
classifiers = [
|
|
12
|
+
"Development Status :: 1 - Planning",
|
|
13
|
+
"Environment :: Console",
|
|
14
|
+
"Intended Audience :: Developers",
|
|
15
|
+
"Programming Language :: Python :: 3",
|
|
16
|
+
"Programming Language :: Python :: 3 :: Only",
|
|
17
|
+
"Topic :: Software Development :: Quality Assurance",
|
|
18
|
+
]
|
|
19
|
+
|
|
20
|
+
[project.urls]
|
|
21
|
+
Homepage = "https://github.com/joji-opensource/charter"
|
|
22
|
+
Issues = "https://github.com/joji-opensource/charter/issues"
|
|
23
|
+
|
|
24
|
+
[project.scripts]
|
|
25
|
+
dev-charter = "dev_charter.cli:main"
|
|
26
|
+
|
|
27
|
+
[build-system]
|
|
28
|
+
requires = ["hatchling>=1.27"]
|
|
29
|
+
build-backend = "hatchling.build"
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Copyright 2026 Joji John
|
|
2
|
+
# SPDX-License-Identifier: Apache-2.0
|
|
3
|
+
"""The `dev-charter` command."""
|
|
4
|
+
|
|
5
|
+
import click
|
|
6
|
+
|
|
7
|
+
REPOSITORY = "https://github.com/joji-opensource/charter"
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
@click.group(invoke_without_command=True)
|
|
11
|
+
@click.version_option(package_name="dev-charter", prog_name="Dev Charter")
|
|
12
|
+
@click.pass_context
|
|
13
|
+
def main(ctx: click.Context) -> None:
|
|
14
|
+
"""Dev Charter: know what your product does, which code delivers it, and what is proven."""
|
|
15
|
+
if ctx.invoked_subcommand is None:
|
|
16
|
+
click.echo("Dev Charter is in early development and has no commands yet.")
|
|
17
|
+
click.echo(f"Follow {REPOSITORY} to hear when the first release ships.")
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
version = 1
|
|
2
|
+
revision = 3
|
|
3
|
+
requires-python = ">=3.11"
|
|
4
|
+
|
|
5
|
+
[[package]]
|
|
6
|
+
name = "click"
|
|
7
|
+
version = "8.5.0"
|
|
8
|
+
source = { registry = "https://pypi.org/simple" }
|
|
9
|
+
sdist = { url = "https://files.pythonhosted.org/packages/c7/0e/7fa0ef50764b67090eca4114772a2abf8b6148198475e54c660b97caeee6/click-8.5.0.tar.gz", hash = "sha256:ba0d2089de75ea0310e2dde03160e6ca10009947fb95a182f9b54021bb272e34", size = 382235, upload-time = "2026-08-26T13:33:14.56Z" }
|
|
10
|
+
wheels = [
|
|
11
|
+
{ url = "https://files.pythonhosted.org/packages/58/50/6c0d534c5f134586a8e1ba4e330569e32f057e33372ae556463212fb4cd3/click-8.5.0-py3-none-any.whl", hash = "sha256:255bc9599cf7748b4b1a446ccc735421bd08a2ae529a8b88597d3de5664ee360", size = 125251, upload-time = "2026-08-26T13:33:12.928Z" },
|
|
12
|
+
]
|
|
13
|
+
|
|
14
|
+
[[package]]
|
|
15
|
+
name = "dev-charter"
|
|
16
|
+
version = "0.0.1"
|
|
17
|
+
source = { editable = "." }
|
|
18
|
+
dependencies = [
|
|
19
|
+
{ name = "click" },
|
|
20
|
+
]
|
|
21
|
+
|
|
22
|
+
[package.metadata]
|
|
23
|
+
requires-dist = [{ name = "click", specifier = ">=8.1,<9" }]
|