[id774]

Background and Purpose

A cross-repository review identified inconsistencies in the wording,
formatting, and line wrapping of shared documentation and boilerplate.
Previous formatting changes were made independently, allowing text intended
to remain consistent across repositories to diverge.

This pull request aligns the shared wording, formatting, and maintenance
policies with the common standard. Repository-specific requirements,
behavior, licensing conditions, and historical records remain unchanged
unless a change to them has been explicitly approved.

The purpose is not another independent prose-formatting pass. It is to make
shared text and maintenance decisions consistent, to keep applicable rules
self-contained, and to distinguish common standards from legitimate local
requirements. The full standard below records the cross-repository decision,
including provisions that do not apply to the repository containing this pull
request. The repository-specific results appear separately.

The common rules are integrated into the existing policy by subject and
responsibility. Consistency of wording does not require identical document
structures. A general rule is stated once in its appropriate existing section,
and repository-specific constraints remain with the responsibility they govern.
A README remains an overview, not a second implementation policy.

Cross-Repository Unification Guidelines

ID	Subject	Common standard and rationale	Applicability and preservation
G01	Scope	Standardize shared documents and maintenance conventions across maintained repositories. Do not include inactive projects or third-party mirrors merely because they exist or have recent commits. Treat the shared standard as one coherent change.	Apply only to maintained, project-owned material. Do not change unrelated projects, external source, or historical archives.
G02	Canonical prose	Use the same approved wording, physical line breaks, blank lines, punctuation, Markdown structure, and formatting for shared blocks. Common boilerplate takes precedence over independent line wrapping.	Preserve existing numbering, heading hierarchy, and separators where required by the containing document. Do not normalize unrelated prose.
G03	Ordinary prose	Prefer natural English sentences and approximately 80 columns. Slight excess is acceptable when needed for readability. Use meaningful punctuation rather than status prefixes, unexplained symbols, or semicolon chains.	Do not break links, URLs, tables, code, identifiers, machine-readable syntax, or established literal interfaces. Preserve required non-English content.
G04	Policy structure and responsibility	Integrate each applicable rule into the existing policy section that owns its subject. Replace equivalent general wording rather than appending a separate collection of common rules.	Keep the policy hierarchy, existing project-specific obligations, and document roles. Do not create a catch-all section, a duplicate rule, or a partial policy merely to install common text. A repository without a suitable policy requires a separate design decision.
R01	Primary Branch	Use the complete English branch-name explanation in R1, including its two paragraphs and technical-identifier clarification.	Retain the equivalent established Japanese text in a Japanese policy document. Keep master as the branch identifier, not a political or social statement. Preserve existing section numbering and place the branch section before License where both exist.
R02	Standard README license	Use R2 for software distributed under the GPLv3/LGPLv3 dual license. Use the same Markdown link labels and wrapping.	The extensionless doc/LICENSE variant changes only that link's displayed path and destination. Do not rename license files. Add the standard section where the maintained software README lacks it.
R03	README license exclusions	Use R3 where the dual license covers only the parts copyrighted by the maintainer. Retain the local explanation of exclusions and the actual license-file references.	Do not imply that bundled third-party code or derived files are covered by the maintainer's license. Existing exclusion details and rights must not be lost.
R04	Contributor-owned project	Retain the existing project name, developer copyright notice, creator attribution, authors-file link, and the established license explanation for a project with collective authorship.	Do not replace project-specific copyright ownership with a single maintainer's notice. Common license documents still receive L1's clarification.
R05	Market data license	Use R4 verbatim for the shared Source Code and Market Data explanation. The source license does not authorize use or redistribution of market data or its derived content. The data provider's terms remain applicable.	Applies to maintained market-data software. Preserve locally accurate packaging, dependency, bundled-asset, generated-file, and test-fixture disclosures in the appropriate subsection. Do not change data handling or provider terms.
R06	Mixed content license	Preserve the distinction between software under the dual license and documentation, photographs, or images under a different license.	Keep the existing CC BY-ND 4.0 reference and offline legal text where they apply. Do not extend the software license to other content or create a license for a repository without an established grant.
R07	Contribution boilerplate	Remove the generic contribution section rather than maintaining an arbitrary subset of contribution invitations, fork instructions, or generic requests for well-structured code.	Preserve actual contribution constraints, policy references, validation requirements, and project-specific development information outside the removed section. Update local table-of-contents links, numbering, and references without renumbering unrelated material unnecessarily.
R08	Closing thanks	Remove the generic closing sentence Thank you for using and contributing to this repository!.	No replacement farewell or generic contribution invitation is introduced.
R09	README responsibility	Keep the README an overview of purpose, scope, usage, structure, relevant documentation, and licensing.	A concise reference or explanation of a document role is appropriate. Do not reproduce detailed implementation or maintenance rules in the README. Preserve the repository's existing language and information architecture.
L01	License document	Use the complete L1 standard text, legal-text references, copyright and contact formatting.	Preserve existing doc/LICENSE or doc/LICENSE.md paths. Apply only to repositories with an established GPLv3/LGPLv3 dual license.
L02	Copyright holder reuse	Include the identical reuse and relicensing clarification in L1 in every applicable license document. Replace earlier shorter, longer, or differently wrapped equivalent explanations with it.	The recipient's license is not a restriction on the right holder's own separate use of material for which all necessary rights are held. No new right to relicense third-party material or contributions is granted.
L03	Third-party exclusions	For repositories with excluded third-party or derived code, replace the standard opening with L2 and use L3 rather than maintaining a file-by-file list.	Preserve original notices, attribution, applicable license conditions, and rights of third parties. Do not remove source-level notices or change legal coverage.
L04	Copyright notices	Retain the correct copyright holder and contact notice, including project-specific collective authorship and years where present.	Do not replace existing collective authorship or introduce an inaccurate copyright claim.
L05	Legal texts	Leave the official GPLv3, LGPLv3, and other applicable legal texts unchanged. They are not ordinary prose-formatting targets.	Do not normalize their URLs, spelling, wrapping, or line endings as part of this change.
P01	Governing principle	Adopt the detailed P1 statement of Simplicity is robustness. in the applicable existing implementation or maintenance policy. Avoid unnecessary complexity, redundant checks, speculative layers, and unnecessary operational assumptions while satisfying all actual requirements.	Keep project-specific architecture, compatibility, security, and validation obligations. The common principle does not waive them.
P02	Agent authorization	Adopt P2. An authorized work branch and pull request are the default. A direct commit or push to master requires specific explicit maintainer authorization. Merge and auto-merge require their own explicit authorization.	One operation does not authorize another. Human maintainer authority remains unchanged. A policy provision does not itself authorize a specific direct primary-branch update, merge, auto-merge, or history rewrite.
P03	Pull request scope	Adopt P3. One coherent higher-level purpose is one pull request and one commit, even when it affects several files. Do not split mechanically by finding or include unrelated cleanup.	Review corrections amend the coherent commit only under authorized history-rewrite conditions. Use --force-with-lease on the reviewed branch only when explicitly authorized; check the complete base-to-head change. Merge remains a maintainer decision.
P04	English writing	Adopt P4 for comments, docstrings, documentation, version histories, release notes, commits, and pull request descriptions.	Preserve structural syntax, literal interface strings, and required non-English text. Never rewrite past entries merely for style.
P05	Wording strength	Adopt the detailed P5 rule. Reserve absolute terms for invariants without reasonable exceptions, qualify preferences, and respect purpose, safety, compatibility, approved scope, and explicit maintainer decisions.	A convention does not override a legitimate maintainer decision or an applicable specification.
P06	Risk of changing established behavior	Adopt P6. Compare the probability and impact of the prevented failure with complexity, new failure modes, compatibility, operation, maintenance, and rollback costs.	Do not treat a theoretical risk alone as sufficient reason to change stable infrastructure.
P07	Safety and complexity	Adopt P7. Safety priority does not automatically justify a more complex design; evaluate the total change and its new risks.	Keep the existing required safety obligations and decision priorities.
P08	Established behavior	Adopt P8. Reliable long-running behavior is evidence. Modernity, apparent cleanliness, or extra defensiveness alone does not justify refactoring.	Clear defects or explicitly approved changes remain distinct from arbitrary refactoring.
P09	Implementation scope and validation	Adopt P9. Implementation changes must be explicitly in scope; validate in the supported and representative environments affected by the change.	A convenient environment alone is insufficient for a change whose compatibility risk extends beyond it.
P10	Scope separation	Adopt P10. Documentation, policy, review, diagnostics, or cleanup work must not turn into implementation work without an approved implementation scope.	Do not fix unrelated findings during this standardization.
P11	Change acceptance	Adopt P11. Evaluate the smallest coherent change, effects outside its purpose, unnecessary dependencies or side effects, privacy, and directly affected documentation.	Preserve meaningful existing behavior and constraints.
P12	Specification authority	Adopt P12. Each concrete specification has one authoritative home appropriate to its responsibility. Other documents may summarize or link without creating competing normative copies.	Within each repository, preserve existing document roles and authority. The shared standard is locally self-contained, not a runtime dependency on another repository.
P13	Policy self-containment	Adopt P13. The complete applicable implementation and maintenance policy lives in the repository itself. An uncovered subject is a local policy gap.	Preserve the existing policy document's role, language, and authority. A repository that is not a single software product may have a different governance structure. Do not create a competing rule hierarchy or a partial implementation policy to satisfy text uniformity.
P14	Implementation and specification	Adopt both paragraphs of P14. The implementation shows actual behavior but is not itself proof of intended behavior. Resolve discrepancies using the interface, header, history, design, and maintenance intent.	Do not turn a regression into a specification by documenting it.
P15	Third-party attribution	Adopt P15. Credit adapted third-party material and respect copyright, license, and redistribution conditions.	Preserve original attribution and rights. This policy does not authorize relicensing external material.
P16	Comments	Adopt P16. Comments preserve reasons, constraints, non-obvious intent, or decisions. Do not restate obvious code.	Preserve meaningful source comments and existing header metadata. Do not refactor implementation.
P17	Browser extensions	Adopt the complete P17 block verbatim for browser extensions. Limit purpose, responsibilities, permissions, data access, communications, persistence, dependencies, and contexts; treat web content and generated output as untrusted.	Require an explicit specification decision before expanding capabilities. Report limitations or fail safely without silently expanding authority or claiming unperformed verification. Non-extension repositories do not acquire browser-specific obligations.
V01	Version history scope	Use V1 for repositories that maintain repository release histories. Record externally meaningful or architecturally significant outcomes, not a commit diary. Omit reverted or superseded intermediate work; combine related low-level changes.	A repository without a release history does not acquire one solely from this standard. Do not rewrite existing release entries.
V02	Release item form	Use one coherent change per bullet, normally one line and at most two, with about 80 columns. Abstract details before wrapping; preserve the changed target, externally observable behavior, compatibility, privacy, security impact, and necessary identifiers.	Necessary names and identifiers may exceed 80 columns. Preserve an established historical layout where V1 explicitly allows it. Do not apply ordinary prose wrapping to the canonical guidelines themselves.
V03	Release item grouping	Group changes by substantive outcome; keep related entries adjacent; append independent changes to the current version entry.	A change to several files may be one item. Independence determines grouping, not a second version on the same day.
V04	Calendar-date invariant	Never create more than one repository version for the same calendar date. Independent changes share the single entry for that date.	The same invariant also applies independently to each versioned source file. Existing historical same-date releases remain recorded as they were; they are not precedent.
V05	Historical records	Preserve previous release text, dates, numbers, and grouping. Do not rewrite, renumber, or merge past entries.	The standard changes guidance, not the historical record.
V06	Initial release	A genuine first release is recorded only as Initial release.. Remove obsolete project-specific generic initial-release wording.	Preserve historical first-commit records. Only an established rewritten-system release history uses the explicit V3 exception; do not relabel a modernization or rewrite as the initial release.
V07	Unreleased versions	An unreleased entry uses (Release Date: TBD). Replacing TBD with the actual date is the release, not a new change item.	Preserve existing release processes and numbering schemes. Do not create provisional release entries before the initial release where existing policy prohibits them.
V08	History inclusion	Changes not observable from outside do not need a repository entry; documentation-only changes take none unless their scale merits one concise entry.	Apply repository-level criteria, not one bullet per commit or per file. This policy-standardization change does not itself introduce a release or rewrite release history.
V09	File versus repository history	File-level Version History, where used, is independent of repository release history. A change to one versioned unit does not by itself require changing the other.	Do not introduce per-file histories into projects that version only at repository level or do not version individual files.
V10	Git tags and releases	Recording a repository version does not create or require a Git tag or GitHub Release. Either requires an explicit maintainer request.	No tag, release, version-number change, or release publication is performed in this standardization.
V11	Shared data contract	Use V2 in both the producer and consumer of shared data. A format or interpretation change is recorded in the release history and doc/DATA_CONTRACT.md in the same commit.	Field meaning and position must remain consistent; no silent divergence. Applies only to shared-data-contract software. This change does not modify any data contract.
V12	Revised-system first entry	Use V3 for the history of a substantially revised existing system whose first recorded version is not its actual initial release.	Preserve the existing first entry in both affected histories. V3 is not an exception for unrelated histories.
S01	Source header metadata	Retain S1's author, source URL, license, and contact format for project-owned files using this header convention. Only repository and other legitimate local metadata values vary.	Never overwrite third-party attribution, collective authorship, actual license terms, or a different established comment syntax.
S02	Header structure	Retain the established S2 structure, names, spacing, and separators for files using that convention. Keep the actual description, requirements, usage, and applicable history.	Preserve existing Options, Exit Codes, Routes, Test Cases, Environment Variables, and other required fields. Do not add executable-only sections to libraries or impose a file history on unversioned files.
S03	Source file version numbers	Adopt S3 for individually versioned source files: major.minor, rollover from .9 to the next major .0, maintainer decision for other major changes, and explicit incompatible-change wording.	This is not the repository release scheme. Preserve calendar-based, three-component, or other established repository release numbers; do not renumber old file versions or introduce file-level versioning where absent.
G04	Change boundaries	Apply the common policy only within its actual domain. Keep specific documentation roles, copyright, data conditions, release model, and supported environments.	A rule in this table does not require a new license grant, release history, browser capability, or file-header scheme where none exists. No executable behavior, dependencies, build, test expectations, configuration, or data formats change.
G05	Verification	Compare canonical shared blocks exactly, inspect all applicable locations and their local constraints, validate links and heading references, check the full final diff, and confirm no release-history or legal-text mutation.	Record actual local changes and validation separately. A non-applicable standard remains in this table; it is not presented as an implemented feature.

Canonical Wording

The following reference blocks record the exact shared wording and formatting.
They are the same in each pull request. A repository-specific heading number,
comment syntax, license path, project name, copyright notice, or other stated
local value is substituted only where the corresponding guideline permits it.
A block that is not applicable is still included here as part of the common
standard; its inclusion does not mean it was installed in this repository.

R1 — Primary Branch

## Primary Branch

This repository uses `master` as its primary branch name.

The name is used solely as a technical identifier, following the long-standing
convention historically used by Git. It does not express or imply any
association with racism, slavery, discrimination, or any political or social
ideology.

R2 — Standard README License

## License

This repository is dual licensed under the
[GPL version 3](https://www.gnu.org/licenses/gpl-3.0.html) or the
[LGPL version 3](https://www.gnu.org/licenses/lgpl-3.0.html), at your option.
For full details, please refer to [doc/LICENSE.md](doc/LICENSE.md). See also
[doc/COPYING](doc/COPYING) and [doc/COPYING.LESSER](doc/COPYING.LESSER) for the
complete license texts.

R3 — README License Opening for Third-Party Exclusions

The parts of this repository copyrighted by id774 are dual licensed under the
[GPL version 3](https://www.gnu.org/licenses/gpl-3.0.html) or the
[LGPL version 3](https://www.gnu.org/licenses/lgpl-3.0.html), at your option.

R4 — Market Data README License

## License

### Source Code

The source code in this repository is dual licensed under the
[GPL version 3](https://www.gnu.org/licenses/gpl-3.0.html) or the
[LGPL version 3](https://www.gnu.org/licenses/lgpl-3.0.html), at your option.
For full details, please refer to [doc/LICENSE.md](doc/LICENSE.md). See also
[doc/COPYING](doc/COPYING) and [doc/COPYING.LESSER](doc/COPYING.LESSER) for the
complete license texts.

### Market Data

The market data used by this software is not covered by the source code
license.

Prices, indicators derived from them, and charts based on them originate
from the J-Quants API and remain subject to the provider's terms of service.
Those terms permit personal investment analysis and prohibit redistributing
the data or providing a continuing analysis service to third parties.

Publishing the source code does not grant permission to publish the data.
Nothing in the GPL or LGPL grants rights to the market data or its derived
content.

Read and follow the provider's terms of service before using this software.

L1 — Standard License Document

# License

This software is distributed under a **dual license**:
You may choose either the [GNU General Public License v3](https://www.gnu.org/licenses/gpl-3.0.html)
or the [GNU Lesser General Public License v3](https://www.gnu.org/licenses/lgpl-3.0.html), at your discretion.

For the full legal text, please refer to the included files:
- [`COPYING`](COPYING) (GPLv3)
- [`COPYING.LESSER`](COPYING.LESSER) (LGPLv3)

The licenses above govern permissions granted to recipients. They do not
restrict a copyright holder from separately reusing, relicensing, or
incorporating material for which that copyright holder owns all necessary
rights into another work under different terms. This clarification does not
grant any right to relicense third-party material or contributions for which
the necessary rights are not held.

---

© [id774](https://id774.net)
Contact: [idnanashi@gmail.com](mailto:idnanashi@gmail.com)

L2 — License Opening for Third-Party Exclusions

The parts of this software copyrighted by id774 are distributed under a
**dual license**:

L3 — Third-Party Software

## Third-Party Software

Third-party software bundled with this repository, and files that consist
of or contain code derived from third-party software, are excluded from the
dual license described above.

Such software and files remain subject to the applicable original copyright
notices, license conditions, and other terms.

P1 — Governing Principle

## 0. Governing Principle

**Simplicity is robustness.**

This is the governing principle for every rule below. It does not authorize
dropping required behavior, compatibility, security, safety, documentation, or
validation. It requires satisfying those requirements with no more complexity
than the actual problem justifies.

Complexity is itself a source of failure, compatibility risk, operational risk,
security risk, and maintenance cost. Do not add a branch, state variable,
helper, abstraction, dependency, network boundary, retry, fallback, validation,
configuration state, or framework unless the specification requires it or it
addresses a realistic failure mode with meaningful consequence.

Do not re-check a condition already guaranteed by a preceding successful
operation or an established invariant. Do not create a layer merely to resemble
a possible future architecture.

When two designs satisfy the same requirements, choose the one with less
control flow, less state, fewer dependencies, fewer side effects, fewer moving
parts, and fewer operational assumptions. Simplicity is judged by the number of
necessary concepts and behaviors, not by line count alone.

P2 — Agent Authorization

Unless explicitly instructed otherwise by the maintainer, an automated agent
must commit authorized changes to a work branch and submit them through a
pull request targeting the approved base branch.

An automated agent must not commit or push directly to `master` without
explicit instructions from the maintainer authorizing that operation.

Creating or updating a pull request does not authorize the agent to merge it
or enable auto-merge. Either action requires an explicit instruction from
the maintainer.

Authorization for one operation does not imply authorization for another.
These rules do not change a human maintainer's authority.

P3 — Pull Request Scope and History

A pull request carries one coherent higher-level purpose, which may require
coordinated changes across several files or responsibilities.

Do not split one approved purpose mechanically by individual finding, file,
or review comment, and do not include unrelated cleanup, formatting, or
feature work.

Represent one coherent change as one commit and amend review corrections
instead of accumulating follow-up commits.

Rewriting the history of a branch under review requires an explicit
instruction from the maintainer. When such a rewrite is authorized, use
`--force-with-lease` and limit the operation to the branch under review.

Check the final branch against its base to remove abandoned intermediate
wording and work. Merge only with explicit maintainer approval.

P4 — English Prose and Shared Boilerplate

Write English explanatory prose in clear, natural sentences. Do not replace a
sentence with a label and a colon, a status prefix such as `Implement:` or
`Incompatible:`, a symbol, or an unexplained abbreviation.

Apply this to English prose in comments, docstrings, documentation, version
histories, release notes, commit messages, and pull request descriptions.

This rule does not alter the established forms of headings, list labels,
tables, code, configuration syntax, machine-readable fields, literal
interface strings, or non-English content required by the repository's
purpose.

Wrap ordinary prose at approximately 80 columns where practical. Preserve
the logical structure of paragraphs, lists, and other document elements.
Do not break URLs, code, tables, identifiers, or other elements whose
structure requires a longer line.

Shared boilerplate must retain its common wording, line breaks, blank lines,
and formatting. Do not reformat it independently in individual repositories.
Its established common form takes precedence over the ordinary line-wrapping
guideline.

Do not rewrite historical entries or unrelated text merely to align their
style.

P5 — Wording Strength

Use `must`, `always`, and `never` only for invariants that admit no reasonable
exception. Express preferences and situational decisions with `prefer`,
`should`, or other qualified wording.

Do not apply a rule literally where doing so would defeat the repository's
stated purpose, intended behavior, compatibility, safety, or approved change
scope.

Where the applicable specifications and policy leave a legitimate choice
open, an explicit maintainer decision governs that choice. General
conventions do not override it.

P6 — Risk Assessment

Before changing established behavior, weigh the probability and impact of the
failure being prevented against the added complexity, new failure modes,
compatibility risk, operational cost, maintenance cost, and rollback cost.

P7 — Safety and Complexity

A safety-motivated change is not automatically justified by Safety having
priority over Efficiency. Added complexity can itself create new failure
modes, compatibility risk, operational risk, and maintenance cost. Evaluate
the proposed change as a whole.

P8 — Established Behavior

Behavior that has operated reliably over time is evidence and has value of
its own. Do not refactor established infrastructure merely because another
design appears cleaner, more modern, or more defensive.

P9 — Implementation Scope and Validation

An implementation change is made only when that change has been explicitly
chosen as part of the work being performed. Before deployment, validate it in
the supported and representative environments affected by the change. A
successful check in one convenient environment is not sufficient evidence for
a change whose compatibility risk extends to other supported environments.

P10 — Scope Separation

Documentation work, policy work, review, diagnostics, cleanup, or another
task whose stated scope does not include an implementation change must not
expand into one merely because an improvement opportunity is discovered.

P11 — Change Acceptance

Before accepting a change, ask whether it is the smallest coherent change that
serves its purpose, whether it alters behavior outside that purpose, whether it
adds an unnecessary dependency or side effect, whether it exposes private
information, and whether directly affected documentation remains correct.

P12 — Specification Authority

A concrete specification has exactly one authoritative home appropriate to the
responsibility that owns it. Other documents may link to or summarize that
specification for navigation, but they do not create a competing normative
copy.

P13 — Policy Self-Containment

This document stands on its own. It is the whole implementation policy of this
repository, and no rule here is completed by a document kept somewhere else. A
subject it does not cover is a gap in this document, to be filled here rather
than looked up elsewhere.

P14 — Implementation and Specification

The implementation is the primary evidence of what currently happens. It is
not, by itself, proof that the current behavior is the intended specification.

When implementation and documentation disagree, compare the implementation,
documented interface, component header, history, existing design, and
maintenance intent. If the implementation contains a regression, do not adopt
that regression as the specification merely because it is present in the
current code.

P15 — Third-Party Attribution

Content adapted from an external article, answer, documentation example, source
file, dataset, or other third-party material credits its source and respects
the license or redistribution terms that apply to it.

P16 — Comments

A comment preserves a reason, constraint, non-obvious intent, or decision that
a later change could otherwise undo. Do not use comments merely to restate code
whose operation is already evident.

P17 — Browser Extension Design Principles

### 0.1 Browser Extension Design Principles

A browser extension exists to assist the user with a specific operation, not to
assume responsibilities beyond that operation. Its behavior must remain within
the purpose, scope, and boundaries established by the requirements.

Keep responsibilities, permissions, data access, external communication,
persistence, dependencies, and execution contexts to the minimum necessary for
the approved operation. A capability must not be added merely because it is
technically possible or might make the result more comprehensive.

Treat web page content, external responses, and AI-generated output as untrusted
data. None of them may authorize additional operations, broaden permissions,
introduce communication destinations, or cross an established trust boundary.

Before adding external resource retrieval, navigation, authentication, broader
site access, unrequested background processing, or new data transmission,
establish why the capability is necessary for the stated purpose. Identify its
security, privacy, and maintenance consequences, and obtain an explicit
specification decision before implementation.

When the intended operation cannot be completed within the established
boundaries, report the limitation or fail safely. Do not silently expand the
extension's responsibilities or permissions to overcome that limitation. Do not
claim a level of verification that the operation has not actually performed.

V1 — Version History Guidelines

Version History Guidelines
==========================
- Record externally meaningful or architecturally significant outcomes, not a
  diary of implementation work.
- Omit development-time corrections and intermediate states that were reverted
  or superseded before release. Git history retains that detail.
- Summarize related low-level changes under their substantive outcome.
- Write one coherent change per bullet, at most two physical lines.
- A single line at or under 80 columns is preferred whenever practical.
  Names and identifiers necessary to describe the change may pass 80 columns
  on the bullet's one or two lines when they cannot be shortened without
  losing meaning.
- When a version history already exists, balance a new entry against the
  length of the existing lines, so that the whole file stays consistent.
  Holding to the form this file has settled on comes before the two-line,
  80-column limit above, and leaves that limit standing wherever no such
  form exists.
- When an entry becomes substantially longer, omit or abstract implementation
  details, examples, reasons, and secondary effects where possible.
- Preserve the changed target, externally observable behavior, compatibility,
  privacy and security impact, and important names and identifiers.
- Combine related changes within the same version, especially changes to the
  same file or feature.
- Place closely related entries near each other.
- Append an independent new change to the end of the current version entry.
- Never create more than one repository version for the same calendar date.
- Independent changes may use separate bullets, but they stay in that day's
  single version entry.
- Past entries and their dates are a record. Do not rewrite, renumber or merge
  them. Past releases that share a date stay recorded as they were made. They
  do not conform to the rule above and are not precedent for new releases.
- The first entry, at the lowest version this file reaches, reads only
  "Initial release." and nothing else.
- An unreleased entry carries (Release Date: TBD). Replacing TBD with the
  actual date is the release itself, and is not a change to record here.
- This file records the history of the repository. A change that is not
  observable from outside does not need an entry here, and a documentation
  only change takes none unless its scale makes it worth one line saying so.
- Where individual source files carry their own Version History, that history
  records changes to the file independently of the repository release history.
  A repository release entry does not raise a source-file version, and a
  source-file version change does not by itself require a repository release
  entry. Record it here only when the change meets the repository-level
  criteria above.
- Recording a repository version here does not create or require a Git tag or
  GitHub Release. Either is created only when the maintainer explicitly asks
  for it.

V2 — Shared Data Contract

- A change to the format or interpretation of a shared data file is recorded
  here and in doc/DATA_CONTRACT.md in the same commit.
- The producer and consumer must remain consistent with the data contract,
  including the meaning and position of fields. A change on either side
  must not introduce a silent divergence from that contract.

V3 — Revised-System First Entry

- The first version recorded here is a release of a substantially revised
  existing system, not its initial release. Preserve the existing entry for
  that version and do not replace it with "Initial release."

S1 — Source Header Metadata

#  Author: id774 (More info: https://id774.net)
#  Source Code: https://github.com/id774/<repository>
#  License: The GPL version 3, or LGPL version 3 (Dual License).
#  Contact: idnanashi@gmail.com

S2 — Source Header Structure

########################################################################
# <file>: <summary>
#
#  Description:
#  <description>
#
#  Author: id774 (More info: https://id774.net)
#  Source Code: https://github.com/id774/<repository>
#  License: The GPL version 3, or LGPL version 3 (Dual License).
#  Contact: idnanashi@gmail.com
#
#  Usage:
#  <usage>
#
#  Requirements:
#  <requirements>
#
#  Version History:
#  <version> <date>
#       <change description>
#
########################################################################

S3 — Source File Version Numbering

### Source File Version Numbering

These rules apply to individual source files that carry their own version
history. Repository release versions are governed separately.

- Source file versions use a two-level `major.minor` scheme.
- When incrementing `minor` would reach `10`, roll over instead: increment
  `major` by 1 and reset `minor` to `0` (for example `v0.9` -> `v1.0`,
  `v1.9` -> `v2.0`, `v2.9` -> `v3.0`).
- Do not continue `minor` past `9` as in standard semantic versioning
  (do not use `v1.10`, `v1.11`, ...).
- Raising `major` for a reason other than the rollover is a decision the
  maintainer makes, not one this document derives from the change.
- Removing or renaming an option, changing what an existing argument means,
  changing a default so that an unchanged invocation does something else, and
  changing how a path or a configuration value is resolved are all incompatible
  changes. Say so in the `Version History` entry, so that the number the change
  is released under can be chosen knowing that.

README License Reference Variants

For a repository with the extensionless license document, the standard
license block is identical to R2 except for this link:

[doc/LICENSE](doc/LICENSE)

For a repository with a maintainer-owned license and third-party exclusions,
the local README may retain this explicit reference:

For exclusions and full license details, please refer to the
[LICENSE](doc/LICENSE) file.
See also [COPYING](doc/COPYING) and [COPYING.LESSER](doc/COPYING.LESSER) for the
complete license texts.

A README that explicitly describes bundled third-party material keeps the
actual local path and existing distinction between bundled code and files
containing third-party derived code. The following parameterized form
records the wording without naming another repository or its paths:

The third-party software bundled under `<bundled-third-party-path>` is excluded
from this dual license and follows the license conditions of each third-party
software.
The same exclusion applies to the individual files that contain third-party
derived code.

For full details, please refer to the [LICENSE](doc/LICENSE) file. See also
[COPYING](doc/COPYING) and [COPYING.LESSER](doc/COPYING.LESSER) for the complete
license texts.

The collective-authorship variant retains the following pattern, with the
existing actual project name, copyright notice, and contributor references:

<project name> is dual-licensed under the
[GNU General Public License, Version 3](https://www.gnu.org/licenses/gpl-3.0.html)
or the
[GNU Lesser General Public License, Version 3](https://www.gnu.org/licenses/lgpl-3.0.html).
You may choose either license at your discretion.

See [`doc/LICENSE.md`](doc/LICENSE.md), [`doc/COPYING`](doc/COPYING) and
[`doc/COPYING.LESSER`](doc/COPYING.LESSER) for the full license texts.

<existing collective copyright notice>

Project created by [id774](https://id774.net). Contributors are listed in
[`doc/AUTHORS`](doc/AUTHORS).

The local market-data license additions retain the following facts wherever
already applicable. These are not interchangeable across different software:

`pyproject.toml` carries the matching `license` field, and every source module
repeats the terms in its header block.

Third-party components keep their own licenses. This repository bundles none.
Its dependencies are installed from PyPI and are listed in `pyproject.toml`.

The generated files are excluded from version control, and no market data
obtained from the provider is committed as a test fixture.

The bundled third-party assets retain their respective MIT licenses.

The following repository-specific content is preserved rather than replicated
across repositories: actual collective copyright notices and authors-file
references, specific third-party exclusion explanations in a README, mixed
content licensing, and the accurate local source-code or market-data facts.
The common license document replaces individual third-party file lists with
L3 but retains original notices within the affected material. The source-file
version rule is conditional on existing file-level version management.

The policy blocks above define wording, not a new document hierarchy. They
belong to the existing sections responsible for design principles, change
discipline, documentation authority, validation, licensing, comments, or
versioning, as applicable. Retain the existing section hierarchy and the local
conditions that make the rules operational. Do not collect those blocks in an
additional cross-repository maintenance section. In particular, a general
policy rule does not replace a project-specific compatibility, privacy,
validation, release, or integration constraint.

For release-history formatting, the Version History Guidelines in the
repository history are the authority. A settled existing form has priority
over the ordinary two-line, 80-column limit. A policy that describes the
history follows that same rule. V3 is the explicit exception to V1 for an
existing history whose first recorded version is a substantially revised
system rather than its initial release. A historical First Commit record is
not itself a release version and is not rewritten. Source-file history rules
do not create new file-level version management.

Changed

• doc/LICENSE.md (L01, L02, L04): replaced with the complete L1 text. The
  copyright line keeps the collective notice
  Copyright (c) 2012-2026 Automatic Ruby Developers., and the Contact line
  is unchanged.
• doc/POLICY.md: each shared rule is placed in the existing section that
  owns its subject (G04). Where a rule sits inside an existing list, only the
  list's structural indentation is added.
  • The opening paragraph is P13, and section 0 is P1.
  • Section 1.3 (Design philosophy): P16 and P5 replace the equivalent bullets
    on comments and wording strength. The three-layer statement is kept.
  • Section 1.4 (Change discipline): P10, P6, P7, P8 and P9 follow the first
    paragraph and replace the improvement-opportunity paragraph. The
    paragraphs on layered evaluation, safety mechanisms in trusted single-user
    tooling, long-running operational history and composition-model changes
    are kept.
  • Section 1.13 (Judging a change): P11 opens the section and replaces the
    smallest-change question. The other questions are kept.
  • Section 1.14 (Pull Request Scope and History): P3 and P2.
  • Section 2.1 (Style): P4 replaces the English prose bullet. The Ruby
    100-column code guideline is kept.
  • Section 2.3 (File headers): the per-file history statement now applies to
    Ruby files. The Ruby header labels and alignment are unchanged.
  • Section 8 (Documentation): P12 precedes the document table, whose
    introduction now reads "The documents divide as follows:". P14 and P15
    follow the table.
  • Section 10.4: the line-length bullets are aligned with the version history
    guidelines, so a settled form takes priority over the two-line, 80-column
    limit.
  • New section 10.6 (Source File Version Numbering): S3 with a statement
    that it applies to the versioned shell build script, not to Ruby files.
• doc/VERSIONS (V01): the text from Version History Guidelines to the end
  of the file is V1.
• script/build (S01): the header label Source Code:: is corrected to
  Source Code:.
• Not applied: R01 and the collective-authorship License section (R04)
  already matched. There is no contribution section and no closing thanks
  sentence (R07, R08). The README stays an overview (R09). R02, R03, R05, R06,
  L03, P17, V11 and V12 do not apply. The Ruby files use the header syntax
  defined in section 2.3, so S01 and S02 do not apply to them.

Preserved behavior

• No executable code, configuration, dependency, test, CI workflow or data
  changed. The only change outside documentation is one comment line in
  script/build.
• README.md, doc/COPYING, doc/COPYING.LESSER and doc/AUTHORS are
  byte-identical to the base.
• The headings, numbering, separators, link targets and code fences of
  doc/POLICY.md are kept. The only added heading is section 10.6. No
  catch-all section exists.
• The repository-specific invariants, layered change discipline, Recipe and
  plugin contract checks, network-free test rule, single-user safety
  conditions, linear composition model, Ruby header convention and
  repository-level versioning are unchanged.

Version History

VERSION, lib/automatic/version.rb and all version numbers are unchanged.
In doc/VERSIONS, every release record before Version History Guidelines
is byte-identical to the base, and only the guidelines at the foot changed.
No release entry was added. The file-level history in script/build is
unchanged, and no file-level history was introduced for Ruby files.

Validation

ID	Check	Result	Expected	Observed (exit code)
C01	Read the remote, the PR metadata, base, head and commit before the change.	PASS	Specified starting state	Base 3ec8ba9, head 78a7e17, merge base equals base, 1 commit, clean worktree
C02	Extracted the doc/POLICY.md headings before and after, and located each rule.	PASS	No catch-all section, rules in their assigned sections	Only section 10.6 added. Shared Maintenance Rules occurs 0 times
C03	Matched the canonical P1-P16 and S3 text against the actual placement.	PASS	Each block once, in its assigned section	Every block occurs once in its section. P17 is absent
C04	Compared the repository-specific provisions with the base and the previous head.	PASS	No removal or weakening	The retained paragraphs, questions and conventions are present
C05	Compared README.md with the base.	PASS	Overview unchanged	Byte-identical
C06	Compared the license document, legal texts and authors file.	PASS	Only the approved license explanation changed	COPYING, COPYING.LESSER and AUTHORS are byte-identical
C07	Compared doc/VERSIONS before the guidelines with the base, and checked the history rules in the policy against V1.	PASS	Records unchanged, rules consistent	Records byte-identical. Section 10.4 matches V1
C08	Checked the changed paths against the base.	PASS	Only the four permitted files	doc/LICENSE.md, doc/POLICY.md, doc/VERSIONS, script/build
C09	Ran git diff --check and compared links, fences and separators.	PASS	Exit 0, structure intact	0. The link set is unchanged. 6 fences and 11 separators before and after
C10	Reviewed the commits and diff from base to head after the amend.	PASS	One commit on the base	1 commit whose parent is 3ec8ba9. Message unchanged
C11	Compared the shared section of this body with the common standard.	PASS	Byte-identical	See Pull Request Verification
C12	Read back the PR metadata after the update.	PASS	Open, non-draft, unmerged, 1 commit	See Pull Request Verification

Smoke test

No runtime or deployment smoke test was run. Executable code and configuration
are byte-identical to the base, and runtime tests are outside the scope of
this documentation change. The existing CI ran automatically on the updated
head. The Ruby 3.3, 3.4 and 4.0 jobs and the optional-plugin workflow all
succeeded.

Exit status

git diff --check: 0. All 8 CI check runs concluded with success. The byte
and placement comparisons have no exit status.

Diff

4 files changed, 200 insertions, 66 deletions: doc/LICENSE.md,
doc/POLICY.md, doc/VERSIONS and script/build.

Branch and Commit

• Base: master at 3ec8ba90d310382cabcfc2217646683f954203d6
• Branch: docs/standardize-shared-boilerplate-20261112
• Commit: 36af2b34bd94483bc66bf1fca0cb7418def361a3, "Standardize shared
  documentation and maintenance policies"
• Scope: one commit directly on the base, and every changed file is in the
  approved scope.

Pull Request Verification

Read back after the update: base master (3ec8ba9), head
docs/standardize-shared-boilerplate-20261112 (36af2b3), and the title as
specified. The shared section from ## Background and Purpose through the end
of the Canonical Wording is byte-identical to the common standard. No private
information is included. 1 commit and 4 changed files. The pull request is
open, non-draft and unmerged. Auto-merge was never enabled. The available
interface does not report the auto-merge state directly.