Prepare the v0.11.2 release

Remove the policy adoption narrative
Align policies with the standard and record their provenance
2026-09-28 00:02:23 +00:00 · 2026-09-28 00:01:57 +00:00 · 2026-09-27 21:18:11 +00:00 · 2026-09-27 21:10:12 +00:00 · 2026-09-27 13:40:57 +00:00 · 2026-09-26 21:48:47 +00:00
25 changed files with 2098 additions and 1128 deletions
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,5 +1,6 @@
-Please review `docs/development.md` for initial orientation in this repository
+Start with `docs/development.md` for orientation and use its policy reading guide
-and follow its task-specific reading guide.
+to select the policies applicable to the task. Do not read the entire suite by
 default.
-Review and follow `docs/policy/agents.md` before recommending, planning, or
+Read and follow `docs/policy/agents.md` before recommending, planning, or
-implementing any changes to this repository.
+implementing repository changes.
--- a/674
+++ b/674
@@ -1,674 +0,0 @@
                    GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007
 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
                            Preamble
  The GNU General Public License is a free, copyleft license for
 software and other kinds of works.
  The licenses for most software and other practical works are designed
 to take away your freedom to share and change the works.  By contrast,
 the GNU General Public License is intended to guarantee your freedom to
 share and change all versions of a program--to make sure it remains free
 software for all its users.  We, the Free Software Foundation, use the
 GNU General Public License for most of our software; it applies also to
 any other work released this way by its authors.  You can apply it to
 your programs, too.
  When we speak of free software, we are referring to freedom, not
 price.  Our General Public Licenses are designed to make sure that you
 have the freedom to distribute copies of free software (and charge for
 them if you wish), that you receive source code or can get it if you
 want it, that you can change the software or use pieces of it in new
 free programs, and that you know you can do these things.
  To protect your rights, we need to prevent others from denying you
 these rights or asking you to surrender the rights.  Therefore, you have
 certain responsibilities if you distribute copies of the software, or if
 you modify it: responsibilities to respect the freedom of others.
  For example, if you distribute copies of such a program, whether
 gratis or for a fee, you must pass on to the recipients the same
 freedoms that you received.  You must make sure that they, too, receive
 or can get the source code.  And you must show them these terms so they
 know their rights.
  Developers that use the GNU GPL protect your rights with two steps:
 (1) assert copyright on the software, and (2) offer you this License
 giving you legal permission to copy, distribute and/or modify it.
  For the developers' and authors' protection, the GPL clearly explains
 that there is no warranty for this free software.  For both users' and
 authors' sake, the GPL requires that modified versions be marked as
 changed, so that their problems will not be attributed erroneously to
 authors of previous versions.
  Some devices are designed to deny users access to install or run
 modified versions of the software inside them, although the manufacturer
 can do so.  This is fundamentally incompatible with the aim of
 protecting users' freedom to change the software.  The systematic
 pattern of such abuse occurs in the area of products for individuals to
 use, which is precisely where it is most unacceptable.  Therefore, we
 have designed this version of the GPL to prohibit the practice for those
 products.  If such problems arise substantially in other domains, we
 stand ready to extend this provision to those domains in future versions
 of the GPL, as needed to protect the freedom of users.
  Finally, every program is threatened constantly by software patents.
 States should not allow patents to restrict development and use of
 software on general-purpose computers, but in those that do, we wish to
 avoid the special danger that patents applied to a free program could
 make it effectively proprietary.  To prevent this, the GPL assures that
 patents cannot be used to render the program non-free.
  The precise terms and conditions for copying, distribution and
 modification follow.
                       TERMS AND CONDITIONS
  0. Definitions.
  "This License" refers to version 3 of the GNU General Public License.
  "Copyright" also means copyright-like laws that apply to other kinds of
 works, such as semiconductor masks.
  "The Program" refers to any copyrightable work licensed under this
 License.  Each licensee is addressed as "you".  "Licensees" and
 "recipients" may be individuals or organizations.
  To "modify" a work means to copy from or adapt all or part of the work
 in a fashion requiring copyright permission, other than the making of an
 exact copy.  The resulting work is called a "modified version" of the
 earlier work or a work "based on" the earlier work.
  A "covered work" means either the unmodified Program or a work based
 on the Program.
  To "propagate" a work means to do anything with it that, without
 permission, would make you directly or secondarily liable for
 infringement under applicable copyright law, except executing it on a
 computer or modifying a private copy.  Propagation includes copying,
 distribution (with or without modification), making available to the
 public, and in some countries other activities as well.
  To "convey" a work means any kind of propagation that enables other
 parties to make or receive copies.  Mere interaction with a user through
 a computer network, with no transfer of a copy, is not conveying.
  An interactive user interface displays "Appropriate Legal Notices"
 to the extent that it includes a convenient and prominently visible
 feature that (1) displays an appropriate copyright notice, and (2)
 tells the user that there is no warranty for the work (except to the
 extent that warranties are provided), that licensees may convey the
 work under this License, and how to view a copy of this License.  If
 the interface presents a list of user commands or options, such as a
 menu, a prominent item in the list meets this criterion.
  1. Source Code.
  The "source code" for a work means the preferred form of the work
 for making modifications to it.  "Object code" means any non-source
 form of a work.
  A "Standard Interface" means an interface that either is an official
 standard defined by a recognized standards body, or, in the case of
 interfaces specified for a particular programming language, one that
 is widely used among developers working in that language.
  The "System Libraries" of an executable work include anything, other
 than the work as a whole, that (a) is included in the normal form of
 packaging a Major Component, but which is not part of that Major
 Component, and (b) serves only to enable use of the work with that
 Major Component, or to implement a Standard Interface for which an
 implementation is available to the public in source code form.  A
 "Major Component", in this context, means a major essential component
 (kernel, window system, and so on) of the specific operating system
 (if any) on which the executable work runs, or a compiler used to
 produce the work, or an object code interpreter used to run it.
  The "Corresponding Source" for a work in object code form means all
 the source code needed to generate, install, and (for an executable
 work) run the object code and to modify the work, including scripts to
 control those activities.  However, it does not include the work's
 System Libraries, or general-purpose tools or generally available free
 programs which are used unmodified in performing those activities but
 which are not part of the work.  For example, Corresponding Source
 includes interface definition files associated with source files for
 the work, and the source code for shared libraries and dynamically
 linked subprograms that the work is specifically designed to require,
 such as by intimate data communication or control flow between those
 subprograms and other parts of the work.
  The Corresponding Source need not include anything that users
 can regenerate automatically from other parts of the Corresponding
 Source.
  The Corresponding Source for a work in source code form is that
 same work.
  2. Basic Permissions.
  All rights granted under this License are granted for the term of
 copyright on the Program, and are irrevocable provided the stated
 conditions are met.  This License explicitly affirms your unlimited
 permission to run the unmodified Program.  The output from running a
 covered work is covered by this License only if the output, given its
 content, constitutes a covered work.  This License acknowledges your
 rights of fair use or other equivalent, as provided by copyright law.
  You may make, run and propagate covered works that you do not
 convey, without conditions so long as your license otherwise remains
 in force.  You may convey covered works to others for the sole purpose
 of having them make modifications exclusively for you, or provide you
 with facilities for running those works, provided that you comply with
 the terms of this License in conveying all material for which you do
 not control copyright.  Those thus making or running the covered works
 for you must do so exclusively on your behalf, under your direction
 and control, on terms that prohibit them from making any copies of
 your copyrighted material outside their relationship with you.
  Conveying under any other circumstances is permitted solely under
 the conditions stated below.  Sublicensing is not allowed; section 10
 makes it unnecessary.
  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
  No covered work shall be deemed part of an effective technological
 measure under any applicable law fulfilling obligations under article
 11 of the WIPO copyright treaty adopted on 20 December 1996, or
 similar laws prohibiting or restricting circumvention of such
 measures.
  When you convey a covered work, you waive any legal power to forbid
 circumvention of technological measures to the extent such circumvention
 is effected by exercising rights under this License with respect to
 the covered work, and you disclaim any intention to limit operation or
 modification of the work as a means of enforcing, against the work's
 users, your or third parties' legal rights to forbid circumvention of
 technological measures.
  4. Conveying Verbatim Copies.
  You may convey verbatim copies of the Program's source code as you
 receive it, in any medium, provided that you conspicuously and
 appropriately publish on each copy an appropriate copyright notice;
 keep intact all notices stating that this License and any
 non-permissive terms added in accord with section 7 apply to the code;
 keep intact all notices of the absence of any warranty; and give all
 recipients a copy of this License along with the Program.
  You may charge any price or no price for each copy that you convey,
 and you may offer support or warranty protection for a fee.
  5. Conveying Modified Source Versions.
  You may convey a work based on the Program, or the modifications to
 produce it from the Program, in the form of source code under the
 terms of section 4, provided that you also meet all of these conditions:
    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.
    b) The work must carry prominent notices stating that it is
    released under this License and any conditions added under section
    7.  This requirement modifies the requirement in section 4 to
    "keep intact all notices".
    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.
    d) If the work has interactive user interfaces, each must display
    Appropriate Legal Notices; however, if the Program has interactive
    interfaces that do not display Appropriate Legal Notices, your
    work need not make them do so.
  A compilation of a covered work with other separate and independent
 works, which are not by their nature extensions of the covered work,
 and which are not combined with it such as to form a larger program,
 in or on a volume of a storage or distribution medium, is called an
 "aggregate" if the compilation and its resulting copyright are not
 used to limit the access or legal rights of the compilation's users
 beyond what the individual works permit.  Inclusion of a covered work
 in an aggregate does not cause this License to apply to the other
 parts of the aggregate.
  6. Conveying Non-Source Forms.
  You may convey a covered work in object code form under the terms
 of sections 4 and 5, provided that you also convey the
 machine-readable Corresponding Source under the terms of this License,
 in one of these ways:
    a) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by the
    Corresponding Source fixed on a durable physical medium
    customarily used for software interchange.
    b) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by a
    written offer, valid for at least three years and valid for as
    long as you offer spare parts or customer support for that product
    model, to give anyone who possesses the object code either (1) a
    copy of the Corresponding Source for all the software in the
    product that is covered by this License, on a durable physical
    medium customarily used for software interchange, for a price no
    more than your reasonable cost of physically performing this
    conveying of source, or (2) access to copy the
    Corresponding Source from a network server at no charge.
    c) Convey individual copies of the object code with a copy of the
    written offer to provide the Corresponding Source.  This
    alternative is allowed only occasionally and noncommercially, and
    only if you received the object code with such an offer, in accord
    with subsection 6b.
    d) Convey the object code by offering access from a designated
    place (gratis or for a charge), and offer equivalent access to the
    Corresponding Source in the same way through the same place at no
    further charge.  You need not require recipients to copy the
    Corresponding Source along with the object code.  If the place to
    copy the object code is a network server, the Corresponding Source
    may be on a different server (operated by you or a third party)
    that supports equivalent copying facilities, provided you maintain
    clear directions next to the object code saying where to find the
    Corresponding Source.  Regardless of what server hosts the
    Corresponding Source, you remain obligated to ensure that it is
    available for as long as needed to satisfy these requirements.
    e) Convey the object code using peer-to-peer transmission, provided
    you inform other peers where the object code and Corresponding
    Source of the work are being offered to the general public at no
    charge under subsection 6d.
  A separable portion of the object code, whose source code is excluded
 from the Corresponding Source as a System Library, need not be
 included in conveying the object code work.
  A "User Product" is either (1) a "consumer product", which means any
 tangible personal property which is normally used for personal, family,
 or household purposes, or (2) anything designed or sold for incorporation
 into a dwelling.  In determining whether a product is a consumer product,
 doubtful cases shall be resolved in favor of coverage.  For a particular
 product received by a particular user, "normally used" refers to a
 typical or common use of that class of product, regardless of the status
 of the particular user or of the way in which the particular user
 actually uses, or expects or is expected to use, the product.  A product
 is a consumer product regardless of whether the product has substantial
 commercial, industrial or non-consumer uses, unless such uses represent
 the only significant mode of use of the product.
  "Installation Information" for a User Product means any methods,
 procedures, authorization keys, or other information required to install
 and execute modified versions of a covered work in that User Product from
 a modified version of its Corresponding Source.  The information must
 suffice to ensure that the continued functioning of the modified object
 code is in no case prevented or interfered with solely because
 modification has been made.
  If you convey an object code work under this section in, or with, or
 specifically for use in, a User Product, and the conveying occurs as
 part of a transaction in which the right of possession and use of the
 User Product is transferred to the recipient in perpetuity or for a
 fixed term (regardless of how the transaction is characterized), the
 Corresponding Source conveyed under this section must be accompanied
 by the Installation Information.  But this requirement does not apply
 if neither you nor any third party retains the ability to install
 modified object code on the User Product (for example, the work has
 been installed in ROM).
  The requirement to provide Installation Information does not include a
 requirement to continue to provide support service, warranty, or updates
 for a work that has been modified or installed by the recipient, or for
 the User Product in which it has been modified or installed.  Access to a
 network may be denied when the modification itself materially and
 adversely affects the operation of the network or violates the rules and
 protocols for communication across the network.
  Corresponding Source conveyed, and Installation Information provided,
 in accord with this section must be in a format that is publicly
 documented (and with an implementation available to the public in
 source code form), and must require no special password or key for
 unpacking, reading or copying.
  7. Additional Terms.
  "Additional permissions" are terms that supplement the terms of this
 License by making exceptions from one or more of its conditions.
 Additional permissions that are applicable to the entire Program shall
 be treated as though they were included in this License, to the extent
 that they are valid under applicable law.  If additional permissions
 apply only to part of the Program, that part may be used separately
 under those permissions, but the entire Program remains governed by
 this License without regard to the additional permissions.
  When you convey a copy of a covered work, you may at your option
 remove any additional permissions from that copy, or from any part of
 it.  (Additional permissions may be written to require their own
 removal in certain cases when you modify the work.)  You may place
 additional permissions on material, added by you to a covered work,
 for which you have or can give appropriate copyright permission.
  Notwithstanding any other provision of this License, for material you
 add to a covered work, you may (if authorized by the copyright holders of
 that material) supplement the terms of this License with terms:
    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or
    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or
    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or
    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or
    e) Declining to grant rights under trademark law for use of some
    trade names, trademarks, or service marks; or
    f) Requiring indemnification of licensors and authors of that
    material by anyone who conveys the material (or modified versions of
    it) with contractual assumptions of liability to the recipient, for
    any liability that these contractual assumptions directly impose on
    those licensors and authors.
  All other non-permissive additional terms are considered "further
 restrictions" within the meaning of section 10.  If the Program as you
 received it, or any part of it, contains a notice stating that it is
 governed by this License along with a term that is a further
 restriction, you may remove that term.  If a license document contains
 a further restriction but permits relicensing or conveying under this
 License, you may add to a covered work material governed by the terms
 of that license document, provided that the further restriction does
 not survive such relicensing or conveying.
  If you add terms to a covered work in accord with this section, you
 must place, in the relevant source files, a statement of the
 additional terms that apply to those files, or a notice indicating
 where to find the applicable terms.
  Additional terms, permissive or non-permissive, may be stated in the
 form of a separately written license, or stated as exceptions;
 the above requirements apply either way.
  8. Termination.
  You may not propagate or modify a covered work except as expressly
 provided under this License.  Any attempt otherwise to propagate or
 modify it is void, and will automatically terminate your rights under
 this License (including any patent licenses granted under the third
 paragraph of section 11).
  However, if you cease all violation of this License, then your
 license from a particular copyright holder is reinstated (a)
 provisionally, unless and until the copyright holder explicitly and
 finally terminates your license, and (b) permanently, if the copyright
 holder fails to notify you of the violation by some reasonable means
 prior to 60 days after the cessation.
  Moreover, your license from a particular copyright holder is
 reinstated permanently if the copyright holder notifies you of the
 violation by some reasonable means, this is the first time you have
 received notice of violation of this License (for any work) from that
 copyright holder, and you cure the violation prior to 30 days after
 your receipt of the notice.
  Termination of your rights under this section does not terminate the
 licenses of parties who have received copies or rights from you under
 this License.  If your rights have been terminated and not permanently
 reinstated, you do not qualify to receive new licenses for the same
 material under section 10.
  9. Acceptance Not Required for Having Copies.
  You are not required to accept this License in order to receive or
 run a copy of the Program.  Ancillary propagation of a covered work
 occurring solely as a consequence of using peer-to-peer transmission
 to receive a copy likewise does not require acceptance.  However,
 nothing other than this License grants you permission to propagate or
 modify any covered work.  These actions infringe copyright if you do
 not accept this License.  Therefore, by modifying or propagating a
 covered work, you indicate your acceptance of this License to do so.
  10. Automatic Licensing of Downstream Recipients.
  Each time you convey a covered work, the recipient automatically
 receives a license from the original licensors, to run, modify and
 propagate that work, subject to this License.  You are not responsible
 for enforcing compliance by third parties with this License.
  An "entity transaction" is a transaction transferring control of an
 organization, or substantially all assets of one, or subdividing an
 organization, or merging organizations.  If propagation of a covered
 work results from an entity transaction, each party to that
 transaction who receives a copy of the work also receives whatever
 licenses to the work the party's predecessor in interest had or could
 give under the previous paragraph, plus a right to possession of the
 Corresponding Source of the work from the predecessor in interest, if
 the predecessor has it or can get it with reasonable efforts.
  You may not impose any further restrictions on the exercise of the
 rights granted or affirmed under this License.  For example, you may
 not impose a license fee, royalty, or other charge for exercise of
 rights granted under this License, and you may not initiate litigation
 (including a cross-claim or counterclaim in a lawsuit) alleging that
 any patent claim is infringed by making, using, selling, offering for
 sale, or importing the Program or any portion of it.
  11. Patents.
  A "contributor" is a copyright holder who authorizes use under this
 License of the Program or a work on which the Program is based.  The
 work thus licensed is called the contributor's "contributor version".
  A contributor's "essential patent claims" are all patent claims
 owned or controlled by the contributor, whether already acquired or
 hereafter acquired, that would be infringed by some manner, permitted
 by this License, of making, using, or selling its contributor version,
 but do not include claims that would be infringed only as a
 consequence of further modification of the contributor version.  For
 purposes of this definition, "control" includes the right to grant
 patent sublicenses in a manner consistent with the requirements of
 this License.
  Each contributor grants you a non-exclusive, worldwide, royalty-free
 patent license under the contributor's essential patent claims, to
 make, use, sell, offer for sale, import and otherwise run, modify and
 propagate the contents of its contributor version.
  In the following three paragraphs, a "patent license" is any express
 agreement or commitment, however denominated, not to enforce a patent
 (such as an express permission to practice a patent or covenant not to
 sue for patent infringement).  To "grant" such a patent license to a
 party means to make such an agreement or commitment not to enforce a
 patent against the party.
  If you convey a covered work, knowingly relying on a patent license,
 and the Corresponding Source of the work is not available for anyone
 to copy, free of charge and under the terms of this License, through a
 publicly available network server or other readily accessible means,
 then you must either (1) cause the Corresponding Source to be so
 available, or (2) arrange to deprive yourself of the benefit of the
 patent license for this particular work, or (3) arrange, in a manner
 consistent with the requirements of this License, to extend the patent
 license to downstream recipients.  "Knowingly relying" means you have
 actual knowledge that, but for the patent license, your conveying the
 covered work in a country, or your recipient's use of the covered work
 in a country, would infringe one or more identifiable patents in that
 country that you have reason to believe are valid.
  If, pursuant to or in connection with a single transaction or
 arrangement, you convey, or propagate by procuring conveyance of, a
 covered work, and grant a patent license to some of the parties
 receiving the covered work authorizing them to use, propagate, modify
 or convey a specific copy of the covered work, then the patent license
 you grant is automatically extended to all recipients of the covered
 work and works based on it.
  A patent license is "discriminatory" if it does not include within
 the scope of its coverage, prohibits the exercise of, or is
 conditioned on the non-exercise of one or more of the rights that are
 specifically granted under this License.  You may not convey a covered
 work if you are a party to an arrangement with a third party that is
 in the business of distributing software, under which you make payment
 to the third party based on the extent of your activity of conveying
 the work, and under which the third party grants, to any of the
 parties who would receive the covered work from you, a discriminatory
 patent license (a) in connection with copies of the covered work
 conveyed by you (or copies made from those copies), or (b) primarily
 for and in connection with specific products or compilations that
 contain the covered work, unless you entered into that arrangement,
 or that patent license was granted, prior to 28 March 2007.
  Nothing in this License shall be construed as excluding or limiting
 any implied license or other defenses to infringement that may
 otherwise be available to you under applicable patent law.
  12. No Surrender of Others' Freedom.
  If conditions are imposed on you (whether by court order, agreement or
 otherwise) that contradict the conditions of this License, they do not
 excuse you from the conditions of this License.  If you cannot convey a
 covered work so as to satisfy simultaneously your obligations under this
 License and any other pertinent obligations, then as a consequence you may
 not convey it at all.  For example, if you agree to terms that obligate you
 to collect a royalty for further conveying from those to whom you convey
 the Program, the only way you could satisfy both those terms and this
 License would be to refrain entirely from conveying the Program.
  13. Use with the GNU Affero General Public License.
  Notwithstanding any other provision of this License, you have
 permission to link or combine any covered work with a work licensed
 under version 3 of the GNU Affero General Public License into a single
 combined work, and to convey the resulting work.  The terms of this
 License will continue to apply to the part which is the covered work,
 but the special requirements of the GNU Affero General Public License,
 section 13, concerning interaction through a network will apply to the
 combination as such.
  14. Revised Versions of this License.
  The Free Software Foundation may publish revised and/or new versions of
 the GNU General Public License from time to time.  Such new versions will
 be similar in spirit to the present version, but may differ in detail to
 address new problems or concerns.
  Each version is given a distinguishing version number.  If the
 Program specifies that a certain numbered version of the GNU General
 Public License "or any later version" applies to it, you have the
 option of following the terms and conditions either of that numbered
 version or of any later version published by the Free Software
 Foundation.  If the Program does not specify a version number of the
 GNU General Public License, you may choose any version ever published
 by the Free Software Foundation.
  If the Program specifies that a proxy can decide which future
 versions of the GNU General Public License can be used, that proxy's
 public statement of acceptance of a version permanently authorizes you
 to choose that version for the Program.
  Later license versions may give you additional or different
 permissions.  However, no additional obligations are imposed on any
 author or copyright holder as a result of your choosing to follow a
 later version.
  15. Disclaimer of Warranty.
  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
 APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
 OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
 THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
 IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
 ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
  16. Limitation of Liability.
  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
 THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
 GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
 USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
 EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGES.
  17. Interpretation of Sections 15 and 16.
  If the disclaimer of warranty and limitation of liability provided
 above cannot be given local legal effect according to their terms,
 reviewing courts shall apply local law that most closely approximates
 an absolute waiver of all civil liability in connection with the
 Program, unless a warranty or assumption of liability accompanies a
 copy of the Program in return for a fee.
                     END OF TERMS AND CONDITIONS
            How to Apply These Terms to Your New Programs
  If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
 free software which everyone can redistribute and change under these terms.
  To do so, attach the following notices to the program.  It is safest
 to attach them to the start of each source file to most effectively
 state the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.
    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.
 Also add information on how to contact you by electronic and paper mail.
  If the program does terminal interaction, make it output a short
 notice like this when it starts in an interactive mode:
    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.
 The hypothetical commands `show w' and `show c' should show the appropriate
 parts of the General Public License.  Of course, your program's commands
 might be different; for a GUI interface, you would use an "about box".
  You should also get your employer (if you work as a programmer) or school,
 if any, to sign a "copyright disclaimer" for the program, if necessary.
 For more information on this, and how to apply and follow the GNU GPL, see
 <https://www.gnu.org/licenses/>.
  The GNU General Public License does not permit incorporating your program
 into proprietary programs.  If your program is a subroutine library, you
 may consider it more useful to permit linking proprietary applications with
 the library.  If this is what you want to do, use the GNU Lesser General
 Public License instead of this License.  But first, please read
 <https://www.gnu.org/licenses/why-not-lgpl.html>.
--- a/23
+++ b/23
@@ -0,0 +1,23 @@
 PromptKit
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: LGPL-3.0-or-later
 This library is free software: you can redistribute it and/or modify it
 under the terms of the GNU Lesser General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.
 The GNU Lesser General Public License version 3 is provided in LICENSE.
 This library is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU Lesser General Public License for more details.
 Policy documents copied or adapted from Standard Repository Policies remain licensed
 under CC-BY-SA-4.0. See docs/oss/attribution.md for the affected material,
 upstream credit, and license links.
 Third-party code and assets are subject to their respective license terms.
--- a/693
+++ b/693
@@ -1,21 +1,3 @@
 Promptkit
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: LGPL-3.0-or-later
 This library is free software: you can redistribute it and/or modify it
 under the terms of the GNU Lesser General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.
 This library is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU Lesser General Public License for more details.
 The LGPL version 3 text follows. It incorporates the GPL version 3 text
 provided in COPYING. Dependency code and assets retain their own licenses.
                   GNU LESSER GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007
@@ -181,3 +163,678 @@ whether future versions of the GNU Lesser General Public License shall
 apply, that proxy's public statement of acceptance of any version is
 permanent authorization for you to choose that version for the
 Library.
                    GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007
 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
                            Preamble
  The GNU General Public License is a free, copyleft license for
 software and other kinds of works.
  The licenses for most software and other practical works are designed
 to take away your freedom to share and change the works.  By contrast,
 the GNU General Public License is intended to guarantee your freedom to
 share and change all versions of a program--to make sure it remains free
 software for all its users.  We, the Free Software Foundation, use the
 GNU General Public License for most of our software; it applies also to
 any other work released this way by its authors.  You can apply it to
 your programs, too.
  When we speak of free software, we are referring to freedom, not
 price.  Our General Public Licenses are designed to make sure that you
 have the freedom to distribute copies of free software (and charge for
 them if you wish), that you receive source code or can get it if you
 want it, that you can change the software or use pieces of it in new
 free programs, and that you know you can do these things.
  To protect your rights, we need to prevent others from denying you
 these rights or asking you to surrender the rights.  Therefore, you have
 certain responsibilities if you distribute copies of the software, or if
 you modify it: responsibilities to respect the freedom of others.
  For example, if you distribute copies of such a program, whether
 gratis or for a fee, you must pass on to the recipients the same
 freedoms that you received.  You must make sure that they, too, receive
 or can get the source code.  And you must show them these terms so they
 know their rights.
  Developers that use the GNU GPL protect your rights with two steps:
 (1) assert copyright on the software, and (2) offer you this License
 giving you legal permission to copy, distribute and/or modify it.
  For the developers' and authors' protection, the GPL clearly explains
 that there is no warranty for this free software.  For both users' and
 authors' sake, the GPL requires that modified versions be marked as
 changed, so that their problems will not be attributed erroneously to
 authors of previous versions.
  Some devices are designed to deny users access to install or run
 modified versions of the software inside them, although the manufacturer
 can do so.  This is fundamentally incompatible with the aim of
 protecting users' freedom to change the software.  The systematic
 pattern of such abuse occurs in the area of products for individuals to
 use, which is precisely where it is most unacceptable.  Therefore, we
 have designed this version of the GPL to prohibit the practice for those
 products.  If such problems arise substantially in other domains, we
 stand ready to extend this provision to those domains in future versions
 of the GPL, as needed to protect the freedom of users.
  Finally, every program is threatened constantly by software patents.
 States should not allow patents to restrict development and use of
 software on general-purpose computers, but in those that do, we wish to
 avoid the special danger that patents applied to a free program could
 make it effectively proprietary.  To prevent this, the GPL assures that
 patents cannot be used to render the program non-free.
  The precise terms and conditions for copying, distribution and
 modification follow.
                       TERMS AND CONDITIONS
  0. Definitions.
  "This License" refers to version 3 of the GNU General Public License.
  "Copyright" also means copyright-like laws that apply to other kinds of
 works, such as semiconductor masks.
  "The Program" refers to any copyrightable work licensed under this
 License.  Each licensee is addressed as "you".  "Licensees" and
 "recipients" may be individuals or organizations.
  To "modify" a work means to copy from or adapt all or part of the work
 in a fashion requiring copyright permission, other than the making of an
 exact copy.  The resulting work is called a "modified version" of the
 earlier work or a work "based on" the earlier work.
  A "covered work" means either the unmodified Program or a work based
 on the Program.
  To "propagate" a work means to do anything with it that, without
 permission, would make you directly or secondarily liable for
 infringement under applicable copyright law, except executing it on a
 computer or modifying a private copy.  Propagation includes copying,
 distribution (with or without modification), making available to the
 public, and in some countries other activities as well.
  To "convey" a work means any kind of propagation that enables other
 parties to make or receive copies.  Mere interaction with a user through
 a computer network, with no transfer of a copy, is not conveying.
  An interactive user interface displays "Appropriate Legal Notices"
 to the extent that it includes a convenient and prominently visible
 feature that (1) displays an appropriate copyright notice, and (2)
 tells the user that there is no warranty for the work (except to the
 extent that warranties are provided), that licensees may convey the
 work under this License, and how to view a copy of this License.  If
 the interface presents a list of user commands or options, such as a
 menu, a prominent item in the list meets this criterion.
  1. Source Code.
  The "source code" for a work means the preferred form of the work
 for making modifications to it.  "Object code" means any non-source
 form of a work.
  A "Standard Interface" means an interface that either is an official
 standard defined by a recognized standards body, or, in the case of
 interfaces specified for a particular programming language, one that
 is widely used among developers working in that language.
  The "System Libraries" of an executable work include anything, other
 than the work as a whole, that (a) is included in the normal form of
 packaging a Major Component, but which is not part of that Major
 Component, and (b) serves only to enable use of the work with that
 Major Component, or to implement a Standard Interface for which an
 implementation is available to the public in source code form.  A
 "Major Component", in this context, means a major essential component
 (kernel, window system, and so on) of the specific operating system
 (if any) on which the executable work runs, or a compiler used to
 produce the work, or an object code interpreter used to run it.
  The "Corresponding Source" for a work in object code form means all
 the source code needed to generate, install, and (for an executable
 work) run the object code and to modify the work, including scripts to
 control those activities.  However, it does not include the work's
 System Libraries, or general-purpose tools or generally available free
 programs which are used unmodified in performing those activities but
 which are not part of the work.  For example, Corresponding Source
 includes interface definition files associated with source files for
 the work, and the source code for shared libraries and dynamically
 linked subprograms that the work is specifically designed to require,
 such as by intimate data communication or control flow between those
 subprograms and other parts of the work.
  The Corresponding Source need not include anything that users
 can regenerate automatically from other parts of the Corresponding
 Source.
  The Corresponding Source for a work in source code form is that
 same work.
  2. Basic Permissions.
  All rights granted under this License are granted for the term of
 copyright on the Program, and are irrevocable provided the stated
 conditions are met.  This License explicitly affirms your unlimited
 permission to run the unmodified Program.  The output from running a
 covered work is covered by this License only if the output, given its
 content, constitutes a covered work.  This License acknowledges your
 rights of fair use or other equivalent, as provided by copyright law.
  You may make, run and propagate covered works that you do not
 convey, without conditions so long as your license otherwise remains
 in force.  You may convey covered works to others for the sole purpose
 of having them make modifications exclusively for you, or provide you
 with facilities for running those works, provided that you comply with
 the terms of this License in conveying all material for which you do
 not control copyright.  Those thus making or running the covered works
 for you must do so exclusively on your behalf, under your direction
 and control, on terms that prohibit them from making any copies of
 your copyrighted material outside their relationship with you.
  Conveying under any other circumstances is permitted solely under
 the conditions stated below.  Sublicensing is not allowed; section 10
 makes it unnecessary.
  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
  No covered work shall be deemed part of an effective technological
 measure under any applicable law fulfilling obligations under article
 11 of the WIPO copyright treaty adopted on 20 December 1996, or
 similar laws prohibiting or restricting circumvention of such
 measures.
  When you convey a covered work, you waive any legal power to forbid
 circumvention of technological measures to the extent such circumvention
 is effected by exercising rights under this License with respect to
 the covered work, and you disclaim any intention to limit operation or
 modification of the work as a means of enforcing, against the work's
 users, your or third parties' legal rights to forbid circumvention of
 technological measures.
  4. Conveying Verbatim Copies.
  You may convey verbatim copies of the Program's source code as you
 receive it, in any medium, provided that you conspicuously and
 appropriately publish on each copy an appropriate copyright notice;
 keep intact all notices stating that this License and any
 non-permissive terms added in accord with section 7 apply to the code;
 keep intact all notices of the absence of any warranty; and give all
 recipients a copy of this License along with the Program.
  You may charge any price or no price for each copy that you convey,
 and you may offer support or warranty protection for a fee.
  5. Conveying Modified Source Versions.
  You may convey a work based on the Program, or the modifications to
 produce it from the Program, in the form of source code under the
 terms of section 4, provided that you also meet all of these conditions:
    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.
    b) The work must carry prominent notices stating that it is
    released under this License and any conditions added under section
    7.  This requirement modifies the requirement in section 4 to
    "keep intact all notices".
    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.
    d) If the work has interactive user interfaces, each must display
    Appropriate Legal Notices; however, if the Program has interactive
    interfaces that do not display Appropriate Legal Notices, your
    work need not make them do so.
  A compilation of a covered work with other separate and independent
 works, which are not by their nature extensions of the covered work,
 and which are not combined with it such as to form a larger program,
 in or on a volume of a storage or distribution medium, is called an
 "aggregate" if the compilation and its resulting copyright are not
 used to limit the access or legal rights of the compilation's users
 beyond what the individual works permit.  Inclusion of a covered work
 in an aggregate does not cause this License to apply to the other
 parts of the aggregate.
  6. Conveying Non-Source Forms.
  You may convey a covered work in object code form under the terms
 of sections 4 and 5, provided that you also convey the
 machine-readable Corresponding Source under the terms of this License,
 in one of these ways:
    a) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by the
    Corresponding Source fixed on a durable physical medium
    customarily used for software interchange.
    b) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by a
    written offer, valid for at least three years and valid for as
    long as you offer spare parts or customer support for that product
    model, to give anyone who possesses the object code either (1) a
    copy of the Corresponding Source for all the software in the
    product that is covered by this License, on a durable physical
    medium customarily used for software interchange, for a price no
    more than your reasonable cost of physically performing this
    conveying of source, or (2) access to copy the
    Corresponding Source from a network server at no charge.
    c) Convey individual copies of the object code with a copy of the
    written offer to provide the Corresponding Source.  This
    alternative is allowed only occasionally and noncommercially, and
    only if you received the object code with such an offer, in accord
    with subsection 6b.
    d) Convey the object code by offering access from a designated
    place (gratis or for a charge), and offer equivalent access to the
    Corresponding Source in the same way through the same place at no
    further charge.  You need not require recipients to copy the
    Corresponding Source along with the object code.  If the place to
    copy the object code is a network server, the Corresponding Source
    may be on a different server (operated by you or a third party)
    that supports equivalent copying facilities, provided you maintain
    clear directions next to the object code saying where to find the
    Corresponding Source.  Regardless of what server hosts the
    Corresponding Source, you remain obligated to ensure that it is
    available for as long as needed to satisfy these requirements.
    e) Convey the object code using peer-to-peer transmission, provided
    you inform other peers where the object code and Corresponding
    Source of the work are being offered to the general public at no
    charge under subsection 6d.
  A separable portion of the object code, whose source code is excluded
 from the Corresponding Source as a System Library, need not be
 included in conveying the object code work.
  A "User Product" is either (1) a "consumer product", which means any
 tangible personal property which is normally used for personal, family,
 or household purposes, or (2) anything designed or sold for incorporation
 into a dwelling.  In determining whether a product is a consumer product,
 doubtful cases shall be resolved in favor of coverage.  For a particular
 product received by a particular user, "normally used" refers to a
 typical or common use of that class of product, regardless of the status
 of the particular user or of the way in which the particular user
 actually uses, or expects or is expected to use, the product.  A product
 is a consumer product regardless of whether the product has substantial
 commercial, industrial or non-consumer uses, unless such uses represent
 the only significant mode of use of the product.
  "Installation Information" for a User Product means any methods,
 procedures, authorization keys, or other information required to install
 and execute modified versions of a covered work in that User Product from
 a modified version of its Corresponding Source.  The information must
 suffice to ensure that the continued functioning of the modified object
 code is in no case prevented or interfered with solely because
 modification has been made.
  If you convey an object code work under this section in, or with, or
 specifically for use in, a User Product, and the conveying occurs as
 part of a transaction in which the right of possession and use of the
 User Product is transferred to the recipient in perpetuity or for a
 fixed term (regardless of how the transaction is characterized), the
 Corresponding Source conveyed under this section must be accompanied
 by the Installation Information.  But this requirement does not apply
 if neither you nor any third party retains the ability to install
 modified object code on the User Product (for example, the work has
 been installed in ROM).
  The requirement to provide Installation Information does not include a
 requirement to continue to provide support service, warranty, or updates
 for a work that has been modified or installed by the recipient, or for
 the User Product in which it has been modified or installed.  Access to a
 network may be denied when the modification itself materially and
 adversely affects the operation of the network or violates the rules and
 protocols for communication across the network.
  Corresponding Source conveyed, and Installation Information provided,
 in accord with this section must be in a format that is publicly
 documented (and with an implementation available to the public in
 source code form), and must require no special password or key for
 unpacking, reading or copying.
  7. Additional Terms.
  "Additional permissions" are terms that supplement the terms of this
 License by making exceptions from one or more of its conditions.
 Additional permissions that are applicable to the entire Program shall
 be treated as though they were included in this License, to the extent
 that they are valid under applicable law.  If additional permissions
 apply only to part of the Program, that part may be used separately
 under those permissions, but the entire Program remains governed by
 this License without regard to the additional permissions.
  When you convey a copy of a covered work, you may at your option
 remove any additional permissions from that copy, or from any part of
 it.  (Additional permissions may be written to require their own
 removal in certain cases when you modify the work.)  You may place
 additional permissions on material, added by you to a covered work,
 for which you have or can give appropriate copyright permission.
  Notwithstanding any other provision of this License, for material you
 add to a covered work, you may (if authorized by the copyright holders of
 that material) supplement the terms of this License with terms:
    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or
    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or
    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or
    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or
    e) Declining to grant rights under trademark law for use of some
    trade names, trademarks, or service marks; or
    f) Requiring indemnification of licensors and authors of that
    material by anyone who conveys the material (or modified versions of
    it) with contractual assumptions of liability to the recipient, for
    any liability that these contractual assumptions directly impose on
    those licensors and authors.
  All other non-permissive additional terms are considered "further
 restrictions" within the meaning of section 10.  If the Program as you
 received it, or any part of it, contains a notice stating that it is
 governed by this License along with a term that is a further
 restriction, you may remove that term.  If a license document contains
 a further restriction but permits relicensing or conveying under this
 License, you may add to a covered work material governed by the terms
 of that license document, provided that the further restriction does
 not survive such relicensing or conveying.
  If you add terms to a covered work in accord with this section, you
 must place, in the relevant source files, a statement of the
 additional terms that apply to those files, or a notice indicating
 where to find the applicable terms.
  Additional terms, permissive or non-permissive, may be stated in the
 form of a separately written license, or stated as exceptions;
 the above requirements apply either way.
  8. Termination.
  You may not propagate or modify a covered work except as expressly
 provided under this License.  Any attempt otherwise to propagate or
 modify it is void, and will automatically terminate your rights under
 this License (including any patent licenses granted under the third
 paragraph of section 11).
  However, if you cease all violation of this License, then your
 license from a particular copyright holder is reinstated (a)
 provisionally, unless and until the copyright holder explicitly and
 finally terminates your license, and (b) permanently, if the copyright
 holder fails to notify you of the violation by some reasonable means
 prior to 60 days after the cessation.
  Moreover, your license from a particular copyright holder is
 reinstated permanently if the copyright holder notifies you of the
 violation by some reasonable means, this is the first time you have
 received notice of violation of this License (for any work) from that
 copyright holder, and you cure the violation prior to 30 days after
 your receipt of the notice.
  Termination of your rights under this section does not terminate the
 licenses of parties who have received copies or rights from you under
 this License.  If your rights have been terminated and not permanently
 reinstated, you do not qualify to receive new licenses for the same
 material under section 10.
  9. Acceptance Not Required for Having Copies.
  You are not required to accept this License in order to receive or
 run a copy of the Program.  Ancillary propagation of a covered work
 occurring solely as a consequence of using peer-to-peer transmission
 to receive a copy likewise does not require acceptance.  However,
 nothing other than this License grants you permission to propagate or
 modify any covered work.  These actions infringe copyright if you do
 not accept this License.  Therefore, by modifying or propagating a
 covered work, you indicate your acceptance of this License to do so.
  10. Automatic Licensing of Downstream Recipients.
  Each time you convey a covered work, the recipient automatically
 receives a license from the original licensors, to run, modify and
 propagate that work, subject to this License.  You are not responsible
 for enforcing compliance by third parties with this License.
  An "entity transaction" is a transaction transferring control of an
 organization, or substantially all assets of one, or subdividing an
 organization, or merging organizations.  If propagation of a covered
 work results from an entity transaction, each party to that
 transaction who receives a copy of the work also receives whatever
 licenses to the work the party's predecessor in interest had or could
 give under the previous paragraph, plus a right to possession of the
 Corresponding Source of the work from the predecessor in interest, if
 the predecessor has it or can get it with reasonable efforts.
  You may not impose any further restrictions on the exercise of the
 rights granted or affirmed under this License.  For example, you may
 not impose a license fee, royalty, or other charge for exercise of
 rights granted under this License, and you may not initiate litigation
 (including a cross-claim or counterclaim in a lawsuit) alleging that
 any patent claim is infringed by making, using, selling, offering for
 sale, or importing the Program or any portion of it.
  11. Patents.
  A "contributor" is a copyright holder who authorizes use under this
 License of the Program or a work on which the Program is based.  The
 work thus licensed is called the contributor's "contributor version".
  A contributor's "essential patent claims" are all patent claims
 owned or controlled by the contributor, whether already acquired or
 hereafter acquired, that would be infringed by some manner, permitted
 by this License, of making, using, or selling its contributor version,
 but do not include claims that would be infringed only as a
 consequence of further modification of the contributor version.  For
 purposes of this definition, "control" includes the right to grant
 patent sublicenses in a manner consistent with the requirements of
 this License.
  Each contributor grants you a non-exclusive, worldwide, royalty-free
 patent license under the contributor's essential patent claims, to
 make, use, sell, offer for sale, import and otherwise run, modify and
 propagate the contents of its contributor version.
  In the following three paragraphs, a "patent license" is any express
 agreement or commitment, however denominated, not to enforce a patent
 (such as an express permission to practice a patent or covenant not to
 sue for patent infringement).  To "grant" such a patent license to a
 party means to make such an agreement or commitment not to enforce a
 patent against the party.
  If you convey a covered work, knowingly relying on a patent license,
 and the Corresponding Source of the work is not available for anyone
 to copy, free of charge and under the terms of this License, through a
 publicly available network server or other readily accessible means,
 then you must either (1) cause the Corresponding Source to be so
 available, or (2) arrange to deprive yourself of the benefit of the
 patent license for this particular work, or (3) arrange, in a manner
 consistent with the requirements of this License, to extend the patent
 license to downstream recipients.  "Knowingly relying" means you have
 actual knowledge that, but for the patent license, your conveying the
 covered work in a country, or your recipient's use of the covered work
 in a country, would infringe one or more identifiable patents in that
 country that you have reason to believe are valid.
  If, pursuant to or in connection with a single transaction or
 arrangement, you convey, or propagate by procuring conveyance of, a
 covered work, and grant a patent license to some of the parties
 receiving the covered work authorizing them to use, propagate, modify
 or convey a specific copy of the covered work, then the patent license
 you grant is automatically extended to all recipients of the covered
 work and works based on it.
  A patent license is "discriminatory" if it does not include within
 the scope of its coverage, prohibits the exercise of, or is
 conditioned on the non-exercise of one or more of the rights that are
 specifically granted under this License.  You may not convey a covered
 work if you are a party to an arrangement with a third party that is
 in the business of distributing software, under which you make payment
 to the third party based on the extent of your activity of conveying
 the work, and under which the third party grants, to any of the
 parties who would receive the covered work from you, a discriminatory
 patent license (a) in connection with copies of the covered work
 conveyed by you (or copies made from those copies), or (b) primarily
 for and in connection with specific products or compilations that
 contain the covered work, unless you entered into that arrangement,
 or that patent license was granted, prior to 28 March 2007.
  Nothing in this License shall be construed as excluding or limiting
 any implied license or other defenses to infringement that may
 otherwise be available to you under applicable patent law.
  12. No Surrender of Others' Freedom.
  If conditions are imposed on you (whether by court order, agreement or
 otherwise) that contradict the conditions of this License, they do not
 excuse you from the conditions of this License.  If you cannot convey a
 covered work so as to satisfy simultaneously your obligations under this
 License and any other pertinent obligations, then as a consequence you may
 not convey it at all.  For example, if you agree to terms that obligate you
 to collect a royalty for further conveying from those to whom you convey
 the Program, the only way you could satisfy both those terms and this
 License would be to refrain entirely from conveying the Program.
  13. Use with the GNU Affero General Public License.
  Notwithstanding any other provision of this License, you have
 permission to link or combine any covered work with a work licensed
 under version 3 of the GNU Affero General Public License into a single
 combined work, and to convey the resulting work.  The terms of this
 License will continue to apply to the part which is the covered work,
 but the special requirements of the GNU Affero General Public License,
 section 13, concerning interaction through a network will apply to the
 combination as such.
  14. Revised Versions of this License.
  The Free Software Foundation may publish revised and/or new versions of
 the GNU General Public License from time to time.  Such new versions will
 be similar in spirit to the present version, but may differ in detail to
 address new problems or concerns.
  Each version is given a distinguishing version number.  If the
 Program specifies that a certain numbered version of the GNU General
 Public License "or any later version" applies to it, you have the
 option of following the terms and conditions either of that numbered
 version or of any later version published by the Free Software
 Foundation.  If the Program does not specify a version number of the
 GNU General Public License, you may choose any version ever published
 by the Free Software Foundation.
  If the Program specifies that a proxy can decide which future
 versions of the GNU General Public License can be used, that proxy's
 public statement of acceptance of a version permanently authorizes you
 to choose that version for the Program.
  Later license versions may give you additional or different
 permissions.  However, no additional obligations are imposed on any
 author or copyright holder as a result of your choosing to follow a
 later version.
  15. Disclaimer of Warranty.
  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
 APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
 OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
 THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
 IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
 ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
  16. Limitation of Liability.
  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
 THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
 GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
 USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
 EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGES.
  17. Interpretation of Sections 15 and 16.
  If the disclaimer of warranty and limitation of liability provided
 above cannot be given local legal effect according to their terms,
 reviewing courts shall apply local law that most closely approximates
 an absolute waiver of all civil liability in connection with the
 Program, unless a warranty or assumption of liability accompanies a
 copy of the Program in return for a fee.
                     END OF TERMS AND CONDITIONS
            How to Apply These Terms to Your New Programs
  If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
 free software which everyone can redistribute and change under these terms.
  To do so, attach the following notices to the program.  It is safest
 to attach them to the start of each source file to most effectively
 state the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.
    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.
 Also add information on how to contact you by electronic and paper mail.
  If the program does terminal interaction, make it output a short
 notice like this when it starts in an interactive mode:
    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.
 The hypothetical commands `show w' and `show c' should show the appropriate
 parts of the General Public License.  Of course, your program's commands
 might be different; for a GUI interface, you would use an "about box".
  You should also get your employer (if you work as a programmer) or school,
 if any, to sign a "copyright disclaimer" for the program, if necessary.
 For more information on this, and how to apply and follow the GNU GPL, see
 <https://www.gnu.org/licenses/>.
  The GNU General Public License does not permit incorporating your program
 into proprietary programs.  If your program is a subroutine library, you
 may consider it more useful to permit linking proprietary applications with
 the library.  If this is what you want to do, use the GNU Lesser General
 Public License instead of this License.  But first, please read
 <https://www.gnu.org/licenses/why-not-lgpl.html>.
--- a/README.md
+++ b/README.md
@@ -33,6 +33,12 @@ boundary and constraints that framework work must preserve.
 ## Release Guidance
 The [v0.11.2 release notes](docs/releases/v0.11.2.md) cover policy alignment
 and copied-policy attribution updates.
 The [v0.11.1 release notes](docs/releases/v0.11.1.md) cover the MIT-licensed
 catalog updates and licensing documentation improvements.
 Consumers upgrading to `v0.11.0` should read the
 [v0.11.0 changelog and migration guide](docs/releases/v0.11.0.md), particularly
 the default retry behavior and license change.
@@ -71,16 +77,6 @@ HTTP application built on Promptkit.
 ## License
-Promptkit is licensed under the [GNU Lesser General Public License version 3
+Promptkit is licensed under the [LGPL v3.0 or later](COPYRIGHT).
 or later](LICENSE) (`LGPL-3.0-or-later`). The accompanying [GPLv3 text](COPYING)
 is incorporated by LGPLv3. This maintainer-authorized change applies from this
 revision forward; existing release tags and their license notices are unchanged.
 Dependencies, including the backend catalogs, retain their own licenses.
-Applications may use their own licenses subject to the LGPL's combined-work
+[Open Source attribution notices](docs/oss/attribution.md) are available.
 conditions. Distributors of statically linked Go binaries must account for the
 applicable notices, license copies, library source, and materials and permissions
 needed to recombine or relink with a modified library; installation information
 may also be required. Providing library source alone is not necessarily enough.
 See section 4 of the [LGPL text](LICENSE) for the governing requirements, rather
 than treating this summary as a complete distribution checklist.
--- a/docs/development.md
+++ b/docs/development.md
@@ -1,9 +1,7 @@
 # Development
-This is the contributor entry point for Promptkit, a reusable Go library. All
+This is the contributor entry point for Promptkit, a reusable Go library.
-contributors must read the
+Use the Policy Reading Guide below to select policies applicable to the task.
 [architecture policy](policy/architecture.md) before making changes. Agents must
 also follow the [agent policy](policy/agents.md) before recommendations or work.
 ## Initial Orientation
@@ -16,18 +14,27 @@ Before starting work:
 4. keep documentation limited to implemented behavior unless an accepted
   decision or temporary roadmap explicitly owns future work.
-Start with:
+## Policy Reading Guide
- the [architecture policy](policy/architecture.md) for library boundaries,
+| Policy | Read before… |
-  dependency direction, invariants, and non-goals;
+| --- | --- |
- the [internal component overview](internal/overview.md) for the current
+| [Policy set provenance](policy/meta.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
-  package and component inventory;
+| [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
- the [documentation policy](policy/documentation.md) before changing
+| [Architecture](policy/architecture.md) | Planning or changing library code or its structure. |
-  documentation;
+| [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
- the [testing policy](policy/testing.md) before adding, rewriting, or deleting
+| [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
-  tests; and
+| [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
- the [release policy](policy/release.md) and [release procedure](release.md)
+| [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |
-  for version and publication work.
+
 - Read applicable policies before making decisions they govern; multiple policies
  may apply.
 - Select policies using the task triggers above. Follow cross-references to
  relevant sections when needed to resolve a concrete question.
 - Reuse policies already available in context; reread when changed or no longer
  available.
 - Expand reading when the task's scope expands.
 - When revising a policy itself, read that policy and any provisions elsewhere
  affected by the revision.
 ## Task-Specific Reading Guide
@@ -42,7 +49,8 @@ Start with:
 | Tests or test fixtures | The [testing policy](policy/testing.md), owning package, and focused internal document listed by the component overview. |
 | Maintained example | The [preparation](../examples/go-library/prepare/main.go), [execution](../examples/go-library/run/main.go), and [observation](../examples/go-library/observe/main.go) examples, [consumer guide](consumers/pkg-promptkit.md), [framework format reference](formats.md), and [documentation policy](policy/documentation.md). |
 | Documentation | The [documentation policy](policy/documentation.md) and canonical owner of every affected contract. |
-| Release preparation or publication | The [release policy](policy/release.md) and [release procedure](release.md). |
+| Licensing, dependencies/catalog updates, copied material, or attribution | The [OSS policy](policy/oss.md), [project grant](../COPYRIGHT), [license texts](../LICENSE), and [attribution entries](oss/attribution.md); inspect the selected upstream source's notices. |
 | Release preparation or publication, including release notes | The [release policy](policy/release.md), [release procedure](release.md), and [OSS discoverability rules](policy/oss.md#discoverability). |
 For cross-cutting changes, follow every applicable row. Do not create
 placeholder documents for packages, APIs, or integrations that do not yet
--- a/docs/formats.md
+++ b/docs/formats.md
@@ -346,8 +346,8 @@ cross-version guarantee for these names.
 The external profile inventory is defined by the selected catalog modules, not
 duplicated here. Browse the exact data selected by this Promptkit version:
- [OpenRouter catalog v2.20260922.1 profiles](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/tag/v2.20260922.1/catalog/profiles)
+- [OpenRouter catalog v2.20260926.0 profiles](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/tag/v2.20260926.0/catalog/profiles)
- [Rakestrawhome catalog v2.20260922.0 profiles](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/tag/v2.20260922.0/catalog/profiles)
+- [Rakestrawhome catalog v2.20260926.0 profiles](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/tag/v2.20260926.0/catalog/profiles)
 External profile entries are volatile across catalog releases. The
 [release policy](policy/release.md#catalog-profile-compatibility) owns the precise
--- a/docs/oss/attribution.md
+++ b/docs/oss/attribution.md
@@ -0,0 +1,93 @@
 # Open Source Attribution Notices
 ## Standard Repository Policies
 Material: policy documents under `docs/policy/` and the Policy Reading Guide in
 `docs/development.md`, adapted for this repository; root `AGENTS.md`, copied
 without modification from upstream `agents/AGENTS.md`.
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: CC-BY-SA-4.0
 License and notices: [CC BY-SA 4.0](licenses/CC-BY-SA-4.0.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843).
 ## Promptkit OpenRouter Catalog
 Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2`
 at `v2.20260926.0`.
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: MIT
 License and notices: [MIT](licenses/MIT.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3).
 ## Promptkit Rakestrawhome Catalog
 Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2`
 at `v2.20260926.0`.
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: MIT
 License and notices: [MIT](licenses/MIT.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596).
 ## jsonschema
 Selected module: `github.com/santhosh-tekuri/jsonschema/v6` at `v6.0.2`.
 SPDX-License-Identifier: Apache-2.0
 License and notices: [Apache 2.0](licenses/Apache-2.0.txt) |
 [LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE).
 [Source](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71).
 ## Go Text
 Selected module: `golang.org/x/text` at `v0.14.0` (transitive dependency).
 Copyright (c) 2009 The Go Authors. All rights reserved.
 SPDX-License-Identifier: BSD-3-Clause
 License and notices: [BSD 3-Clause](licenses/BSD-3-Clause.txt) |
 [LICENSE](https://github.com/golang/text/blob/6c97a165dd661335ff7bce6104a008558123c353/LICENSE) |
 [PATENTS](https://github.com/golang/text/blob/6c97a165dd661335ff7bce6104a008558123c353/PATENTS).
 [Source](https://github.com/golang/text/tree/6c97a165dd661335ff7bce6104a008558123c353).
 ## Go YAML v3
 Selected module: `gopkg.in/yaml.v3` at `v3.0.1`.
 Copyright (c) 2006-2010 Kirill Simonov
 Copyright (c) 2006-2011 Kirill Simonov
 Copyright (c) 2011-2019 Canonical Ltd
 Copyright 2011-2016 Canonical Ltd.
 SPDX-License-Identifier: MIT AND Apache-2.0
 License and notices: [MIT](licenses/MIT.txt) |
 [Apache 2.0](licenses/Apache-2.0.txt) |
 [LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
 [NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE).
 [Source](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51).
--- a/docs/oss/licenses/Apache-2.0.txt
+++ b/docs/oss/licenses/Apache-2.0.txt
@@ -0,0 +1,202 @@
                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/
   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
   1. Definitions.
      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.
      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.
      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.
      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.
      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.
      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.
      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).
      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.
      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."
      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.
   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.
   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.
   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:
      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and
      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and
      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and
      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.
      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.
   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.
   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.
   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.
   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.
   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.
   END OF TERMS AND CONDITIONS
   APPENDIX: How to apply the Apache License to your work.
      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.
   Copyright [yyyy] [name of copyright owner]
   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at
       http://www.apache.org/licenses/LICENSE-2.0
   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
--- a/docs/oss/licenses/BSD-3-Clause.txt
+++ b/docs/oss/licenses/BSD-3-Clause.txt
@@ -0,0 +1,11 @@
 Copyright (c) <year> <owner>.
 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--- a/docs/oss/licenses/CC-BY-SA-4.0.txt
+++ b/docs/oss/licenses/CC-BY-SA-4.0.txt
@@ -0,0 +1,170 @@
 Creative Commons Attribution-ShareAlike 4.0 International
 Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
 Using Creative Commons Public Licenses
 Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
 Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
 Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described.
 Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.
 Creative Commons Attribution-ShareAlike 4.0 International Public License
 By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
 Section 1 – Definitions.
     a.	Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
     b.	Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
     c.	BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License.
     d.	Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
     e.	Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
     f.	Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
     g.	License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
     h.	Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
     i.	Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
     j.	Licensor means the individual(s) or entity(ies) granting rights under this Public License.
     k.	Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
     l.	Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
     m.	You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
 Section 2 – Scope.
     a.	License grant.
          1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
               A. reproduce and Share the Licensed Material, in whole or in part; and
               B. produce, reproduce, and Share Adapted Material.
          2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
          3. Term. The term of this Public License is specified in Section 6(a).
          4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
          5. Downstream recipients.
               A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
               B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
               C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
          6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
     b.	Other rights.
          1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
          2. Patent and trademark rights are not licensed under this Public License.
          3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
 Section 3 – License Conditions.
 Your exercise of the Licensed Rights is expressly made subject to the following conditions.
     a.	Attribution.
          1. If You Share the Licensed Material (including in modified form), You must:
               A. retain the following if it is supplied by the Licensor with the Licensed Material:
                    i.	identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
                    ii.	a copyright notice;
                    iii. a notice that refers to this Public License;
                    iv.	a notice that refers to the disclaimer of warranties;
                    v.	a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
               B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
               C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
          2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
          3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
     b.	ShareAlike.In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
          1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
          2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
          3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
 Section 4 – Sui Generis Database Rights.
 Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
     a.	for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
     b.	if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
     c.	You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
 For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
 Section 5 – Disclaimer of Warranties and Limitation of Liability.
     a.	Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
     b.	To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
     c.	The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
 Section 6 – Term and Termination.
     a.	This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
     b.	Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
          1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
          2. upon express reinstatement by the Licensor.
     c.	For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
     d.	For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
     e.	Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
 Section 7 – Other Terms and Conditions.
     a.	The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
     b.	Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
 Section 8 – Interpretation.
     a.	For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
     b.	To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
     c.	No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
     d.	Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
 Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
 Creative Commons may be contacted at creativecommons.org.
--- a/docs/oss/licenses/MIT.txt
+++ b/docs/oss/licenses/MIT.txt
@@ -0,0 +1,18 @@
 MIT License
 Copyright (c) <year> <copyright holders>
 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
 associated documentation files (the "Software"), to deal in the Software without restriction, including
 without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
 following conditions:
 The above copyright notice and this permission notice shall be included in all copies or substantial
 portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
 LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
 EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
 IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
 USE OR OTHER DEALINGS IN THE SOFTWARE.
--- a/docs/policy/agents.md
+++ b/docs/policy/agents.md
@@ -1,19 +1,20 @@
 # Agent Policy
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
 **Upstream Source:** [agents.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md)
 ## Purpose
-Agents must follow these house rules before recommending, planning, or
+Agents must read and follow these rules.
 implementing repository changes.
 ## Implementation Discipline
-Write the simplest idiomatic code that satisfies the user's request.
+**KEY PRINCIPLES:** Write the simplest idiomatic code that satisfies the user's
-Simplify the mechanism, not the user's choices. Do not implicitly strengthen
+request. Do not implicitly strengthen requirements, restrictions, or guarantees
-requirements, restrictions, or guarantees.
+beyond what the user actually requested.
 **Keep implementation machinery proportionate.** Use straightforward,
 idiomatic code and introduce only the machinery needed to support the requested
@@ -28,41 +29,48 @@ operator and caller choice where policy has not been established. If an
 additional restriction appears advisable, present it as a decision rather than
 silently implementing it.
 **Do not invent guarantees.** Do not strengthen public contracts, guarantees,
 or invariants beyond those expressly requested by the user.
 **Use the standard library.** For example: in almost every case, the best
 approach to copying files is to use the standard library. Writing custom code to
 implement power-loss protection at the application level, or to guard against
 bad actors with privileged and concurrent access to the host's filesystem,
 is wasteful, unnecessary, and not idiomatic. Stick to the simple, standard, and
 idiomatic approach unless another path is expressly requested by the user.
 **An implementation detail is not repository policy.** Tests and documentation
 must not elevate incidental behavior into a durable guarantee or restriction
 unless that behavior was expressly selected as part of the contract.
 ## Promptkit Contract Authority
 The following clarification preserves Promptkit's established distinction
 between implementation choices and authorized contracts.
 A correctness constraint must follow from the requested behavior or an
 established invariant, not from the convenience of the chosen implementation.
 Explain the specific failure it prevents and why a less restrictive
 implementation cannot satisfy the contract.
-**An implementation detail is not repository policy.** Tests and documentation
+Existing explicit contracts remain authoritative; changing or weakening one
-must not elevate incidental behavior into a durable guarantee or restriction
+requires a deliberate decision. Agent-authored plans, tests, documentation,
-unless that behavior was expressly selected as part of the contract. Existing
+and prior implementations are not evidence that an additional restriction was
-explicit contracts remain authoritative; changing or weakening one requires a
+deliberately approved. Identify the authorizing requirement or decision; when
-deliberate decision rather than being inferred from this principle.
+that authority is unclear, surface the ambiguity rather than treating repetition
-
+as approval.
 Agent-authored plans, tests, documentation, and prior implementations are not
 evidence that an additional restriction was deliberately approved. Identify the
 authorizing requirement or decision; when that authority is unclear, surface
 the ambiguity rather than treating repetition as approval.
 **Do not invent guarantees.** Do not strengthen public contracts, guarantees,
 or invariants beyond those expressly requested by the user.
 **Use the standard library.** Prefer simple, idiomatic standard-library
 implementations when they satisfy the requested behavior. Do not add custom
 power-loss protection or defenses against privileged concurrent filesystem
 actors unless expressly required. Preserve existing repository contracts.
 ## Git Commit Policy
-By default, create a commit after completing each coherent unit of work, using a
+By default, commit each completed, nonempty unit of work using a
 concise, plain-English message describing what changed. This policy is standing
 authorization to create those local commits; a separate user request is not
 required. An explicit user instruction to leave work uncommitted takes precedence.
 A unit of work is a focused, reviewable outcome, including its relevant tests and
-documentation. Do not commit after every intermediate edit or create empty commits.
+documentation.
 Complete the appropriate validation before committing. If work is incomplete or
-validation is blocked, report that state rather than presenting it as completed.
+validation is blocked, report that state accurately.
 Before committing:
@@ -70,10 +78,10 @@ Before committing:
   changes. Identify changes that predate the current unit of work.
 2. Exclude secrets, local environment files, generated junk, and unrelated changes.
 3. Stage only the files or hunks belonging to the completed unit. Use `git add .`
-   only when every included change belongs to that unit. Do not disturb unrelated
+   only when every included change belongs to that unit. Preserve unrelated
-   staged or unstaged work.
+   staged and unstaged work.
-4. Review `git diff --staged` and run appropriate checks for the change. Do not
+4. Review `git diff --staged` and run appropriate checks for the change. Reuse
-   repeat checks already passed for unchanged content merely to create a commit.
+   successful checks for unchanged content.
 5. Review `git log --oneline -n 10` and use
   `git commit -m "<concise plain-English commit message>"`.
 6. Report the commit identifier and any remaining uncommitted work.
--- a/docs/policy/architecture.md
+++ b/docs/policy/architecture.md
@@ -1,15 +1,41 @@
 # Architecture Policy
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.3
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
-## Purpose
+**Upstream Source:** [architecture.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md)
-This document defines Promptkit's current high-level architecture and the
+## Purpose And Ownership
-durable boundaries that implementation changes must preserve. The
+
-[internal component overview](../internal/overview.md) inventories concrete
+The adopted policy defines Promptkit's purpose and the architectural
-implemented packages without redefining these rules.
+constraints contributors must follow. It owns system boundaries, responsibility
 and dependency rules, established invariants, and explicit non-goals.
 Describe the concrete package inventory and implementation mechanics in internal
 documentation. Link to canonical public contracts for their exact behavior and
 to ADRs for decision rationale.
 ## Architectural Approach
 Hexagonal architecture is strongly recommended, including encapsulating external
 integrations and APIs within internal adapters. Keep domain and application
 logic independent of external integration details, and make dependency direction
 clear in the adopted policy.
 Implement that separation with proportionate, idiomatic code. Choose interfaces
 and package layout to serve the application's actual boundaries. Use adapters
 for collaborators with external integration responsibilities.
 ## Adopted Constraints And Implemented Structure
 Architectural constraints govern current and future development. Record
 implemented structure accurately, proposals and implementation status in the
 roadmap, and significant decisions and rationale in ADRs. Describe a target
 structure as implemented when its changes land.
 Constraints must reflect deliberately selected requirements and decisions.
 Do not promote incidental implementation choices into architectural invariants.
 ## System Shape
@@ -155,3 +181,21 @@ state.
 Do not list planned packages as implemented components. When implementation
 introduces a package, update the internal inventory and the owning contract or
 subsystem document in the same change.
 ## Trust Boundaries And Threat Scope
 Where useful, state the trust boundaries and threat scenarios relevant to the
 application's adopted requirements, along with scenarios it explicitly excludes.
 For example, distinguish handling untrusted application input from defending
 against a privileged actor concurrently modifying the host filesystem.
 Threat exclusions define the scope of the adopted requirements. Base defenses
 and guarantees on those requirements and raise unsettled scope for a deliberate
 decision under the [agent policy](agents.md).
 Keep this discussion proportionate to the application. A separate threat
 assessment or security document is optional when adopting this template.
 For this library, the framework format and integration documents own credential
 supply and external contracts; internal documents own implementation mechanisms.
 Consumer-specific filesystem and security policy remains outside Promptkit's
 boundary as described above.
--- a/docs/policy/documentation.md
+++ b/docs/policy/documentation.md
@@ -1,144 +1,139 @@
 # Documentation Policy
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.11
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
 **Upstream Source:** [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md)
 ## Purpose
-This policy assigns each Promptkit documentation topic to one canonical owner.
+This policy assigns each documentation topic to one canonical owner. Its goal is
-Its goal is to keep documentation for this reusable Go library accurate,
+to keep this library's documentation accurate, concise, discoverable, and resistant
-concise, discoverable, and resistant to drift for consumers, contributors,
+to drift for users, operators, developers, integrators, and LLM coding agents.
 maintainers, integrators, and coding agents.
 ## Core Rules
 ### One Canonical Owner
-Each authoritative fact belongs in one document or source form. A non-owning
+Each authoritative fact belongs in one document. A non-owning document may give
-document may give a short, stable summary for orientation, but it must link to
+a short, stable summary for orientation, but it must link to the canonical owner
-the canonical owner instead of repeating exact contracts.
+for volatile details.
-Volatile details include exported declarations, accepted inputs, defaults,
+Volatile details include commands, flags, configuration fields and defaults,
-schemas, file names, paths, error identities, retry behavior, and runtime
+module keys, schemas, file names, paths, status codes, retry behavior, and
-guarantees. If readers could reasonably treat a statement as a contract,
+runtime guarantees. If readers could reasonably treat a statement as a
-maintain its exact definition only in the owning source.
+contract, maintain it only in the owning document.
-### Current State, Decisions, And Future Work
+### Current And Future Behavior
 Outside `docs/roadmap/`, documentation describes implemented behavior only.
 Partial features may be described only to their implemented boundary.
-An accepted architecture decision may describe an approved direction before it
+Architectural constraints may govern future changes. Describe current structure
-is implemented, but acceptance is not evidence that the behavior exists.
+from implemented behavior.
-Current-state documents change when the implementation lands. Temporary
+
-roadmaps own future work, sequencing, and implementation status; they do not
+ADRs may record an accepted architectural decision before implementation. The
-replace durable policies or current contracts.
+roadmap owns implementation status and sequencing until the decision is
 implemented. Current architecture, user, operator, integration, and internal
 documentation are updated when the behavior lands.
 ### Audience And Detail
 Write for the document's stated audience and include only the detail needed for
-its owned topic. Consumer guidance should not expose incidental implementation
+its owned topic. Keep user and operator docs focused on using and operating the
-detail. Contributor documentation should link to public contracts and durable
+application. Developer docs should link to user-facing and external contracts
-policies instead of restating them.
+for their definitions.
-### Links
+### Examples
-Use descriptive link text and repository-relative links for repository
+Complete copyable files belong in `examples/`. Documentation may use the
-documents. Link to the canonical owner rather than to a duplicate summary.
+smallest illustrative snippet needed to explain its owned topic, but should link
-Check every added or changed link and repair or remove links when their target
+to maintained examples for complete copyable files.
 moves or is retired.
-### Examples And Code Fences
+Examples must be valid, secret-free, and tested where practical. Commands and
-
+configuration used in documentation should match the application.
 Complete copyable files belong in `examples/` when maintained examples exist.
 Documentation may use the smallest illustrative snippet needed for its owned
 topic, but should link to a maintained example instead of embedding a second
 complete copy.
 Examples must be valid, secret-free, and tested where practical. Commands,
 imports, and Go snippets must match the implemented library. Use a language tag
 on fenced code blocks and make clear when a fragment is illustrative rather
 than directly runnable.
 ### Security And Privacy
 Documentation and examples must not contain real credentials, private keys,
-private environment dumps, sensitive source material, or private
+private environment dumps, sensitive source material, or private infrastructure
-infrastructure details unless intentionally public. Document secret-handling
+details unless intentionally public. Document secret-handling mechanisms, not
-mechanisms, not secret values.
+secret values.
 ## Canonical Ownership
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Project orientation | `README.md` | What Promptkit is, its current usability, module identity, license summary, a minimal successful quickstart, and links onward. | Exact API contracts, contributor procedures, architecture detail, and release steps. |
+| Product orientation and minimal end-to-end quickstart | `README.md` | Purpose, value, shortest successful invocation, and navigation, including licensing and attribution. | Complete command reference, configuration reference, operational procedures, implementation detail. |
-| Contributor workflow | `docs/development.md` | Task-oriented reading guide, local workflow, validation commands, and repository hygiene. | Architecture rules, API semantics, subsystem behavior, and release procedure. |
+| Contributor entry point | `docs/development.md` | Task-oriented reading guide, contributor orientation, baseline validation commands, and canonical links. | Package inventory, architecture rules, subsystem behavior, detailed change recipes. |
-| Current architecture | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, package boundaries, invariants, and non-goals. | Concrete component inventory, implementation mechanics, contributor procedures, decision history, and future work. |
+| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
-| Agent policy | `docs/policy/agents.md` | Agent implementation discipline, proportionality, idiomatic simplicity, local commit authorization and discipline, and rules against inventing restrictions, guarantees, or repository policy. | Public contracts, architecture, testing, and contributor procedures. |
+| Policy-set provenance and upstream navigation | `docs/policy/meta.md` | Policy-set origin, local authority, adoption baselines, and upstream adoption and update links. | Task-specific reading triggers, detailed adoption procedures, and formal attribution notices. |
-| Documentation organization | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and document lifecycle. | Library architecture or runtime behavior. |
+| Agent policy | `docs/policy/agents.md` | Proportionate, idiomatic implementation; rules against inventing requirements, restrictions, guarantees, or policy. | Application contracts, architecture, testing policy, and contributor procedures. |
-| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression policy, and test maintenance. | Subsystem behavior, exact public contracts, subsystem-specific test inventories, and implementation plans. |
+| Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
-| Release policy | `docs/policy/release.md` | Versioning, compatibility, release-note requirements, validation obligations, immutability, recovery, and adoption scope. | Executable commands, publication mechanics, and historical release summaries. |
+| Testing policy | `docs/policy/testing.md` | Test philosophy, risk sufficiency, boundaries, doubles, coverage, regressions, and test maintenance. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
-| Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, concrete publication guards and commands, verification, and recovery steps. | Release-policy requirements, public API semantics, and historical summaries. |
+| Release policy | `docs/policy/release.md` | Versioning, compatibility, release integrity and immutability, release documentation, proportionate gates, publication controls, completion, and required versus optional checks. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
 | Open source licensing and attribution policy | `docs/policy/oss.md` | License defaults and author choices, COPYRIGHT and attribution formats, license/notice links, discoverability, maintenance, and concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
 | Project copyright and license grant | `COPYRIGHT` | Project identity, copyright holders and years, SPDX expression, grant, warranty disclaimer, and third-party statement. | Complete license texts and upstream component attribution. |
 | Project license texts | `LICENSE` | Complete project and incorporated companion license texts, with required project-specific fields. | General licensing policy and upstream component attribution. |
 | Upstream component attribution | `docs/oss/attribution.md` | House Format component entries: identity, material scope and modifications where applicable, copyright, license, required notices, and license, notice, and source links. | General attribution policy, exception reasoning, research narratives, compliance commentary, and complete standard license texts. |
 | Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by applicable entries. | Project-specific upstream notices, attribution prose, and policy interpretation. |
 | Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, validation and publication commands and automated guards, asynchronous deliverables, delivery status, optional consumer verification, and recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
 | Consumer guidance for the public Go API (if applicable) | `docs/consumers/` | Task-oriented public Go API usage, minimal examples, and consumer responsibilities. | HTTP wire semantics, external protocol contracts, internal implementation detail. |
 | Integration contracts for external components (if applicable) | `docs/integrations/` | External formats and protocols, upstream and downstream contracts, logical output paths and schemas, media types, and compatibility. | Physical runtime placement and lifecycle, internal transformations, CLI syntax, configuration defaults. |
 | Inventory of implemented internal packages | `docs/internal/overview.md` | Implemented packages and components, responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
 | Behavior and architecture of internal packages | Other files under `docs/internal/` | Implementation flow, collaborators, state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
 | Architectural decision records | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
 | Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status, sequencing, and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
 | Release-note history | `docs/releases/` | One checked-in summary per source release under the procedure; the note at its immutable tag is the release record. | Current commands, behavior, contracts, and compatibility definitions. |
 | Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other copyable or runnable files. | Field-by-field reference, command reference, prose explanation. |
 | Exact exported Go API | Go declarations and GoDoc, as APIs are implemented | Exported names, signatures, types, values, errors, and exact behavioral contracts. | Task-oriented consumer walkthroughs, implementation details, and future API proposals. |
 | Framework file formats | `docs/formats.md` | Prompt-definition and profile YAML fields, schema references, defaults, validation modes, built-in profiles, credentials, and file-to-request precedence. | Exported Go declarations, outbound wire behavior, internal parsing mechanics, and application configuration. |
 | Consumer guidance | `docs/consumers/`, when consumer workflows require dedicated guidance | Task-oriented use of implemented public APIs, minimal examples, and consumer responsibilities. | Exact exported declarations and internal mechanics. |
 | Durable integration contracts | `docs/integrations/`, when integrations exist | External formats and protocols, compatibility behavior, and upstream or downstream responsibilities. | Internal transformations and public Go declarations. |
 | Release-note history | `docs/releases/` | Mandatory version-matched historical summaries for releases made under the adopted release policy; the note at the immutable tag records that release. | Current APIs, behavior, formats, compatibility contracts, and release procedures. |
 | Implemented component inventory | `docs/internal/overview.md` | Current packages and components, their implemented responsibilities, and links to focused internal documents. | Normative architecture, contributor workflow, external contracts, and proposed components. |
 | Internal subsystem behavior | Other files under `docs/internal/`, when a subsystem needs durable detail | Implementation flow, internal collaborators and state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, public API definitions, and future package plans. |
 | Architectural decision history | `docs/adr/`, when repository-local decisions require records | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, and task sequencing. |
 | Temporary feature roadmaps | `docs/roadmap/`, while planned work needs coordination | Proposed or accepted scope, sequencing, gates, and implementation status. | Implemented behavior reference and durable decision rationale. |
 | Complete copyable artifacts | `examples/` | Valid inputs, Go programs, and other files intended to be copied or run. | Field-by-field reference, exact API declarations, and prose explanation. |
-Conditional owners do not require placeholder files or directories. Create a
+Create supporting documents for existing interfaces and responsibilities when
-consumer, integration, release, subsystem, ADR, roadmap, or example document
+substantive content is available.
 only when the corresponding implemented interface, release, decision, planned
 effort, or maintained artifact exists.
 ## Boundary Rules
 ### Orientation
-The README owns project orientation. The development guide routes
+Link among orientation, architecture, and internal documents; maintain each
-contributors. Architecture owns normative structure. The internal overview
+package or behavior description in its canonical owner.
 owns the current concrete component map. These documents may link to one
 another but must not maintain parallel package or behavior descriptions.
 ### Public Contracts And Implementation
-Go declarations and GoDoc own exact exported API contracts once those APIs
+Go declarations and GoDoc own exact exported Go API contracts. The
-exist. Consumer and integration documents explain how to use those contracts
+[framework format reference](../formats.md) owns prompt, profile, and schema
-for a task. Internal documents explain how Promptkit implements them. Internal
+formats; integration documents own external wire behavior. Consumer and
-documentation may identify a public type or external format as a dependency,
+internal documents link to those owners for exact definitions.
 but must link to its canonical definition rather than restate it.
-The [framework format reference](../formats.md) owns exact prompt, profile, and
+### Releases
 schema-file contracts. Integration documents own external wire formats.
-### Release Documentation
+The release policy defines requirements and invariants that every release must
 satisfy. The repository-specific release procedure defines the commands and
 workflow maintainers use to satisfy that policy. Release notes record history
 at immutable tags. Maintain current behavior in its canonical documentation,
 update it with the corresponding behavior changes, and keep release procedures
 consistent with adopted policy.
-The [release policy](release.md) owns release requirements; the
+### Project Licensing And Upstream Attribution
 [repository release procedure](../release.md) owns their concrete execution.
 Version-matched checked-in notes are required for future releases under that
 policy. The source tag is the release identity, and the note in its immutable
 tree is the historical summary; annotated tag messages complement that record.
-Release notes do not own current API or behavior contracts. Link to the
+README and release documents link to the canonical licensing and attribution
-canonical owners for details instead of reproducing those contracts. Published
+materials under the [OSS policy](oss.md). The release procedure owns URL
-notes are not disposable guidance and must not be replaced under the same
+construction and publication mechanics.
 version. Corrections belong in a subsequent release.
-Adoption is prospective. Previously published tags and historical notes retain
+### Contracts And Implementation
-their original records and are not reformatted or rewritten to satisfy the new
+
-requirements.
+Integration and API documents define externally observable shapes and
 semantics. Internal documents explain how this application implements or consumes those
 contracts. Internal docs may name a field, file, or protocol to identify a
 dependency, but must link to its canonical contract for the definition.
 ### Security Topics
 This policy owns what documentation and examples may contain. Architecture owns
-library security boundaries and invariants. Public declarations and integration
+library security boundaries. Public declarations and integration documents own
-documents own consumer-visible security contracts. Internal documents own
+consumer-visible contracts; internal documents own implementation mechanisms.
 implementation mechanisms only.
 ## Architecture Decision Records
@@ -153,31 +148,35 @@ Use sequentially numbered ADR filenames such as
 6. alternatives considered;
 7. consequences.
-Use one of these statuses:
+Treat the decision content of an accepted ADR as immutable. When a decision
 changes, create a new ADR and update the earlier ADR's status to superseded.
 Rejected architectural alternatives belong in the ADR; rejected product ideas
 belong in the roadmap.
- **Proposed:** the decision is under consideration and may change;
+## Maintenance
 - **Accepted:** the decision is approved, whether or not implementation is
  complete;
 - **Rejected:** the proposed decision was considered and not adopted;
 - **Superseded:** a later accepted ADR replaces the accepted decision.
-A proposed ADR transitions to Accepted or Rejected. An Accepted ADR transitions
+When behavior changes, update its canonical owner in the same change. If
-to Superseded only when a later Accepted ADR replaces it. An ADR may be created
+ownership moves, remove the old definition and replace it with a link where
-as Accepted when the decision has already been made.
+navigation remains useful.
-Treat the decision content of an Accepted ADR as immutable. A changed decision
+Before completing documentation work:
-requires a later ADR rather than a rewrite of the accepted record. A Superseded
+
-ADR must link to its replacement, and the replacement must link back. Rejected
+- verify affected behavior and examples;
-architectural alternatives belong in the ADR; rejected feature ideas belong in
+- check commands, flags, fields, defaults, schemas, and paths against their
-a roadmap when they need to be retained.
+  implementation;
 - keep unimplemented behavior in the roadmap, subject to the ADR exception;
 - remove stale references and validate links;
 - confirm that non-owning documents summarize and link rather than redefine;
 - confirm that no secrets or sensitive private data were added.
 ## Promptkit Documentation Scope
 Promptkit is a Go library, so exported GoDoc and framework formats replace
 application CLI, configuration, operations, and HTTP-service owners. Reading
 triggers belong in the development guide, not this topic map.
 ## Document Lifecycle
 Create durable current-state documentation with the implementation it
 describes. Update its canonical owner in the same change when behavior changes.
 If ownership moves, remove the old definition and leave a link where navigation
 remains useful.
 Roadmaps are temporary coordination documents. When their work is complete,
 record completion, move any still-useful decisions or contracts to their
 durable owners, update incoming links, and archive or remove the roadmap
@@ -187,13 +186,9 @@ second current-state reference.
 Retain release notes as historical records under the release policy. Do not
 apply temporary-roadmap retirement rules to published release notes.
-Before completing documentation work:
+For Promptkit ADRs, retain the existing Proposed, Accepted, Rejected, and
-
+Superseded statuses. Proposed records may become Accepted or Rejected;
- verify affected behavior and examples;
+Accepted records may become Superseded, with links between the earlier record
- check commands, imports, declarations, defaults, schemas, and paths against
+and its replacement. Records may be created as Accepted when the decision has
-  their implementation;
+already been made. These lifecycle rules preserve existing local document
- keep unimplemented behavior in a roadmap, subject to the ADR exception;
+semantics.
 - validate links and fenced examples;
 - confirm non-owning documents summarize and link rather than redefine;
 - remove stale or unsupported claims; and
 - confirm that no secrets or sensitive private data were added.
--- a/docs/policy/meta.md
+++ b/docs/policy/meta.md
@@ -0,0 +1,27 @@
 # Policy Set Provenance
 **Base Policy Version:** 1.0
 **Last Updated**: 2026-09-27
 **Upstream Source:** [meta.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md)
 ## Origin And Local Authority
 This repository's policy set is adapted from
 [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
 The adopted local policies govern work in this repository. Upstream revisions
 become local policy through deliberate adoption, preserving local decisions.
 Each policy's `Upstream Source` identifies its adopted baseline.
 ## Adoption And Updates
 For policy adoption, upstream revision reviews, and updates, consult the
 [upstream adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
 That guide and the reference example collection are maintained upstream and
 accessed through links. Keep discovery links pointed at the current upstream
 project and guide; keep adopted-source and example links pinned to commits.
 The local [developer guide](../development.md) routes tasks to applicable
 policies. Formal credit and licensing notices for the copied policy material
 belong in the local [attribution document](../oss/attribution.md).
--- a/docs/policy/oss.md
+++ b/docs/policy/oss.md
@@ -0,0 +1,227 @@
 # Open Source Licensing And Attribution Policy
 **Base Policy Version:** 1.8
 **Last Updated**: 2026-09-27
 **Upstream Source:** [oss.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md)
 ## Purpose And Scope
 This policy defines project licensing conventions and a repeatable House Format
 for upstream attribution and license notices. It covers the project's own code
 and upstream components incorporated into or distributed with the application
 or library, including relevant transitive dependencies and copied code,
 documentation, or assets.
 Determine treatment from the component's terms and actual use.
 Consulting development guidance or using tooling alone does not require an
 attribution entry. Copying or adapting documentation for inclusion in the
 repository is different: preserve its applicable attribution and license terms.
 A material's role as development guidance does not exempt copied documents.
 Apply any express permissions for attribution-free reuse of example formatting.
 The baseline is a publicly available source repository with releases published
 alongside it. The format is independent of language, forge, and build system.
 It does not require attribution for every development tool, establish license
 compatibility, or resolve every obligation arising from use or distribution.
 ## Canonical Locations
 The [documentation policy](documentation.md) assigns ownership:
 - `COPYRIGHT`: project name, copyright statements, SPDX expression, grant,
  warranty disclaimer, and third-party statement.
 - `LICENSE` contains the complete, unmodified project license text, including
  incorporated companion text. Dependency attribution does not relicense the project.
 - `docs/oss/attribution.md`: canonical component entries.
 - `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts.
 Use recognizable license filenames, such as `Apache-2.0.txt` or `LGPL-3.0.txt`.
 A shared standard text may serve multiple entries. Keep explanations outside
 license texts and preserve distinct versions and exceptions.
 ## Upstream Reference Examples
 Use the commit-pinned upstream examples to create actual project notices.
 Retain their links and keep the example collection upstream; keep applicable
 license texts locally as specified above.
 ## Project Licensing
 Unless the author specifies otherwise, use **GPL version 3 or later**
 (`GPL-3.0-or-later`) for applications and **LGPL version 3 or later**
 (`LGPL-3.0-or-later`) for libraries. An author's explicit choice takes precedence:
 for example, a one-off script may use MIT. Such a choice requires no exception
 rationale, additional approval, or compensating controls under this policy.
 These defaults guide new license selection. Adopting this policy does not
 relicense existing code or override third-party terms. Preserve an existing
 license unless the author deliberately changes it. For mixed-purpose projects,
 follow the author's selected scope rather than inferring different licenses for
 individual packages.
 Use the upstream [application COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/application/COPYRIGHT)
 or [library COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/library/COPYRIGHT)
 to create the project’s root `COPYRIGHT` file.
 Use verified project names, contribution years, and copyright holders.
 For another selected license, adapt the grant, SPDX expression, disclaimer, and
 text references together to reflect the author's selected grant.
 For GPLv3 projects, copy the complete GPLv3 text into `LICENSE`. For LGPLv3
 projects, place the complete LGPLv3 text followed by the complete GPLv3 text in
 `LICENSE`; the LGPL incorporates the GPL terms. Keep the texts unmodified and
 place project-specific statements in `COPYRIGHT`. For the default grants, the
 grant and SPDX expression in `COPYRIGHT` must expressly identify `or-later`;
 follow the author’s choice if a different grant is selected.
 For other licenses, provide their complete text and any required project-specific
 fields; the standard reference collection remains unchanged. Keep `COPYRIGHT`,
 `LICENSE`, SPDX expressions, and README descriptions consistent with the actual
 grant. This convention introduces no blanket requirement for per-file headers;
 preserve notices or add them where the applicable terms require them.
 Identify separately licensed documentation or assets in the project grant, with
 links to their attribution and license information. An application's default
 code license does not override the terms of incorporated documentation.
 ## Upstream Attribution House Format
 Begin `docs/oss/attribution.md` with `# Open Source Attribution Notices`,
 followed directly by component entries. These comprise the complete document.
 Each entry presents these five fields in order, with blank lines between them:
 1. **Project name** as a level-two heading. An optional identification paragraph
   may follow, such as `Selected module: MODULE at VERSION.` with the module and
   version in backticks. For copied documentation, a concise `Material:` sentence
   may identify the affected files and whether they were adapted or copied
   without modification. A factual qualifier such as `(transitive dependency)`
   is permitted. Limit optional identification prose to factual component and
   material scope.
 2. **Upstream copyright statement or statements**, preserving their wording.
   Put multiple statements in separate paragraphs. Include this field when the
   selected upstream source supplies an applicable statement; otherwise, omit it.
 3. **SPDX license identifier or expression**, when applicable, using
   `SPDX-License-Identifier: EXPRESSION`.
 4. **License and notice links**, beginning `License and notices:`, separated
   by ` | `, and ending with a period. Label local standard texts by license
   name, such as `MIT` or `Apache 2.0`. Label upstream files by their actual
   filenames, such as `COPYRIGHT`, `LICENSE`, `NOTICE`, or `PATENTS`.
 5. **Source repository link**, rendered exactly as:
   ```markdown
   [Source](COMMIT_URL).
   ```
 Use the upstream [attribution example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/attribution.md)
 to create the project’s `docs/oss/attribution.md`.
 The example illustrates omitted fields and multiple copyrights and licenses.
 Replace the uppercase placeholders and illustrative URLs with actual component
 information. Local license links are relative to the destination
 `docs/oss/attribution.md`; copy the applicable texts into its `licenses/`
 directory. Do not copy example entries for components the project does not use.
 These are five fields, not a line limit. Omit the SPDX field when no applicable
 identifier exists; identify nonstandard terms through the linked text. Preserve
 licensing alternatives and exceptions, and record a selected option when
 relevant through the factual license identification. Do not invent an identifier
 or silently resolve an unsettled licensing choice.
 Keep entries factual. Do not add agent-authored explanations of license
 expressions, file-level license scope, research performed, retained source
 notices, or compliance conclusions. Avoid filler such as "none is invented
 here" and embellished link labels such as "upstream LICENSE", "additional
 patent grant", or "at the imported commit". Preserve actual required upstream
 content; this rule excludes editorial additions, not required notices. Policy
 interpretation and exception reasoning belong in the adopted OSS policy or an
 appropriate decision record, not the attribution document.
 ## License Texts And Upstream Links
 Link standard license texts to their local copies. Link project-specific
 notices to their upstream copies. Every upstream repository or notice link must
 identify the exact commit corresponding to the
 imported version, including the selected source revision for copied material.
 Classify material according to its contents. An upstream `LICENSE`,
 `COPYING`, or similar file may contain project-specific notices or exceptions
 in addition to standard wording. Link both the local standard text and the
 commit-specific upstream file when needed. Make companion license texts directly
 reachable from the entry.
 For project-specific license and attribution material, this policy accepts
 direct links to the applicable upstream texts as satisfying reproduction,
 inclusion, or copy requirements. This is the adopted house interpretation.
 Agents must apply it without adding local-copy requirements or seeking repeated
 approval solely because a license uses those terms.
 This interpretation concerns notice reproduction. Concrete obligations such as
 marking modified files or supplying corresponding source receive their own
 applicable treatment. Preserve required notices already present in incorporated
 source files; the central attribution entry does not authorize stripping them.
 ## Discoverability
 End the project's README with two friendly statements linking to its actual
 grant in `COPYRIGHT` and the attribution document. For example, for a project
 with the stated license:
 ```markdown
 PROJECT_NAME is licensed under the [LGPL v3.0 or later](COPYRIGHT).
 [Open Source attribution notices](docs/oss/attribution.md) are available.
 ```
 Each new checked-in release document and its hosted download page must end
 with links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`. Use absolute
 URLs to those files at the release's immutable tag or corresponding immutable source
 revision so the links work in both locations. This release navigation is distinct
 from upstream component links, which must use the imported commit.
 Reuse the checked-in release document as the hosted release body where supported.
 The release procedure owns concrete URLs and publication mechanics for delivering
 the links through the selected channel. Do not maintain duplicate notice lists.
 These conventions do not by themselves require separate downloadable license
 assets, source bundles, or a different binary package format.
 ## Maintenance And Exceptions
 Update project licensing statements together when the author changes the grant
 or its scope. Update upstream notices in the change that adds, removes, upgrades,
 copies, or changes the distribution of a relevant component. Check the selected source's license
 and notices rather than assuming they are unchanged. Update affected entries,
 commit links, and texts; retain historical versions through Git.
 Check affected statements, faithful standard-text copies, and link destinations
 as part of ordinary change review. For a future release tag, check intended file
 paths against the candidate source; the tag need not resolve remotely before
 publication. Do not add publication-time network checks, CI polling, recurring
 legal sign-offs, mandatory scanners, or a full software bill of materials merely
 to implement this policy.
 Use the House Format routinely. Raise an exception only for a concrete obligation
 or unresolved rights question it does not address, including any arising from a
 particular distribution channel. Record the issue and selected treatment in the
 adopted OSS policy or an appropriate decision record. Attribution entries
 contain the resulting factual identification and required material, without
 repeating that reasoning. Resolve the issue before the affected use or
 distribution without reopening settled choices.
 Common ownership of projects is neither required nor a blanket exception.
 Apply the formatting convention prospectively. Do not rewrite published tags,
 notes, binaries, or checksums to retrofit it. Address actual omissions deliberately
 under the applicable terms and the [release correction policy](release.md#immutability-and-failure-recovery).
 Ordinary attribution maintenance and release links are preparation work, not new
 release approval gates.
 ## Promptkit Adoption
 Promptkit retains its LGPL-3.0-or-later library grant in
 [COPYRIGHT](../../COPYRIGHT). Adapted policy documentation has the separate
 scope identified there and in [attribution](../oss/attribution.md).
 Promptkit publishes source-only Go module tags on Gitea, with no binaries or
 separate hosted download page. The [release procedure](../release.md) owns
 publication and concrete footer URLs. The hosted-page guidance applies if such
 a channel is deliberately introduced; it does not require creating one.
--- a/docs/policy/release.md
+++ b/docs/policy/release.md
@@ -1,30 +1,229 @@
 # Release Policy
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.4
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
-## Purpose And Adoption Scope
+**Upstream Source:** [release.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md)
-This policy owns Promptkit's release requirements and compatibility rules.
+## Purpose
 The [release procedure](../release.md) owns the commands used to satisfy them.
 This scoped adoption applies to releases prepared after its adoption on
 2026-09-23. Published tags and historical notes are not rewritten to retrofit
 the new note format.
-## Release Model And Compatibility
+This policy defines a proportionate workflow for validating and publishing an
 intended source revision under a fresh version. Releases should require little
 routine intervention, avoid repeated work, and preserve published contents.
-Promptkit publishes source-only Go module releases from committed, pushed
+The repository-specific commands belong in `docs/release.md`. Historical release
-`main` candidates through annotated `vMAJOR.MINOR.PATCH` tags. It publishes
+summaries belong in `docs/releases/`. The procedure must agree with the adopted
-no binaries, hosted releases, or other artifacts and uses maintainer-run
+policy and link to it rather than introduce additional release requirements.
 validation rather than hosted CI. Versions must be unused locally and on
 `origin`; the existing procedure accepts stable version tags only.
-Before v1, minor releases may change the public API and patches preserve
+## Release Model And Completion
-compatibility within their minor line, subject to the catalog-data provision
+
-below. Release notes must identify compatibility impact, public API changes,
+A source release identifies one exact committed source revision through an
-and required consumer action. The source tag identifies the exact release;
+immutable version tag and a version-matched, checked-in release note. The
-the checked-in note at that tag records its historical summary.
+primary release branch is `main` unless the adopted policy specifies otherwise.
 The procedure must name the authoritative publication remote.
 A successful push of the intended tag, with its source commit available on the
 authoritative primary branch, completes the release. The source commit may be
 pushed before the tag or published together with it through an atomic push.
 The procedure must choose and document the supported approach.
 Release commands must finish at successful publication. They must not wait for
 or poll CI, require successful CI status, inspect downloadable artifacts, or
 check consumer installation or Go module availability as completion gates.
 A failed or ambiguous push requires resolving the authoritative remote state
 before declaring success or retrying; successful pushes do not require a
 separate remote read-back gate.
 Repositories may publish source only. Additional binaries, images, packages,
 checksums, or other declared deliverables may be published asynchronously from
 the tagged source. The procedure must identify those deliverables and the
 responsibility of their automation. Published deliverables must be traceable
 to that source and identify the same version.
 Track source-release completion and artifact delivery separately. Report delivery
 failures and optional investigations under artifact-delivery status.
 ## Versioning And Compatibility
 Stable releases use Semantic Versioning in the form `vMAJOR.MINOR.PATCH`, with
 no leading zeroes. Prereleases require an explicit adopted policy defining
 their format and use.
 The selected version must be unused locally and on the authoritative remote.
 Do not require queries to every configured remote or publication service.
 A version known to have already been published must not be reused, even if the
 normal guards do not inspect that channel. Adding a distribution channel
 requires a deliberate update to the policy and procedure where needed.
 For releases at or after `v1.0.0`:
 - a major release may make intentional incompatible changes;
 - a minor release may add backward-compatible behavior; and
 - a patch release may make backward-compatible fixes.
 Before `v1.0.0`, a minor release may change a documented public, operational,
 configuration, data, integration, or compatibility contract when the release
 note explains the impact and required consumer action. A patch release must
 not intentionally break those contracts within its minor line.
 Additional compatibility promises and deliberate exceptions belong in the
 adopted policy or canonical contract documentation. Release notes explain
 changes; they do not redefine current compatibility contracts.
 ## Release Documentation
 Every new release must include `docs/releases/<version>.md` in the tagged
 source tree. Use the complete version tag as the filename and begin with a
 title containing the product name and that exact version.
 Include a short summary and any relevant compatibility impact or upgrade
 instructions. Use the Promptkit section structure below and keep the note
 proportionate to the change.
 Keep exact current contracts in their canonical documents and update affected
 documentation with the behavior change. Link to those documents from the note
 where useful. If annotated tags are used, derive their summary from the
 checked-in note.
 Include the release footer defined by the [OSS policy](oss.md#discoverability)
 in each new release document and preserve it on the hosted download page. The
 release procedure defines the concrete URLs and publication mechanics. Prepare
 these links with the release note; they do not add a network check or approval
 gate.
 Handle version selection, release-note content, and retirement of completed
 roadmaps during preparation. Preserve planned and deferred work and repair
 affected links when retiring roadmaps. Reuse ordinary change review for
 unintended files, credentials, and private data. Scope release-content review
 to the tagged source.
 ## Candidate Validation
 Provide one publication command that validates the final committed candidate,
 checks publication state, and publishes the intended refs. A validation-only
 mode or command may be provided for diagnosis, but must not be a required step
 before publication repeats the same checks.
 Run the complete deterministic, offline default test suite once for the final
 candidate, following the [testing policy](testing.md). For repositories that
 publish builds, verify the required build targets. Select those targets for
 the application's actual support commitments; native testing on each platform
 and access to particular hardware are not default release prerequisites.
 Additional gates must address a concrete risk that the existing checks do not
 adequately cover. Do not automatically require linting, race testing, module
 hygiene audits, documentation audits, credential scans, example validation, or
 expanded platform matrices solely because they are possible. Retain such
 checks when their distinct protection justifies their cost. A one-time migration
 check must not silently become a permanent release requirement.
 Release tests must not require real credentials, mutable application services,
 paid APIs, provider probes, or inference calls. The procedure may describe dependency
 preparation separately from offline validation.
 Avoid duplicate validation across release phases. Successful checks for the
 same final candidate need not be repeated solely to satisfy another phase;
 any reuse must clearly apply to that exact candidate. Persistent validation
 caches are not required. If the candidate changes, validate the new candidate.
 Cheap publication-state checks may be repeated immediately before pushing
 because local or remote state may have changed during validation.
 Automate mechanical guards. Human review gates are strongly disfavored: add one
 only through an explicit project-specific policy decision explaining the
 concrete risk and why ordinary change review or automation is insufficient.
 Do not add routine confirmations for checks the command can perform itself.
 ## Publication Guards
 Automate the checks needed to publish the intended source under a fresh version:
 - the version has the adopted format and is unused locally and on the
  authoritative remote;
 - the worktree and index are clean on the primary release branch;
 - the source being published is the exact candidate that passed validation,
  including its matching release note;
 - the remote primary branch already identifies that candidate, or an atomic
  source/tag push will advance it to that candidate without discarding remote
  history; and
 - the tag identifies the validated candidate and only the intended refs are
  published.
 Fetch the authoritative branch and tag state as needed for these checks.
 Do not force branch or tag updates to bypass a failed guard. Publish explicit
 refs rather than all local tags. Do not require CI success, publication-service
 availability checks, or a separate manual confirmation for each guard.
 ## Immutability And Failure Recovery
 Published version tags and published contents are immutable. Do not move,
 overwrite, recreate, or delete a published tag, or replace a published artifact,
 checksum, signature, provenance statement, or release note under that version.
 The checked-in note at the immutable tag is that release's historical record.
 If validation fails before publication, correct and commit the candidate and
 rerun the publication command. If a push fails or its outcome is ambiguous,
 inspect the authoritative remote before retrying. Remove an unpublished local
 tag only after confirming it was never published or used by a release channel.
 An unavailable remote leaves publication status unknown; do not overwrite a tag
 to resolve uncertainty.
 Transient network, authentication, CI, or consumer-availability failures do not
 by themselves require a new version. Asynchronous delivery may be retried from
 the same immutable tag. Missing artifacts may be published later, provided
 existing published contents are not replaced and the additions remain consistent
 with the tagged source and any already-published checksum manifest. If that
 cannot be achieved, publish a new version.
 A defect requiring changes to published source or contents requires a corrected
 commit, a new semantically appropriate version, a matching release note, and
 the release procedure again. Leave the original release intact. A channel's
 yank, deprecation, or advisory mechanism may warn consumers away from a defective
 release without replacing its contents or reusing its version.
 ## Repository Release Procedure
 Maintain `docs/release.md` as a short, executable maintainer runbook. It must
 identify:
 1. prerequisites, primary branch, and authoritative remote;
 2. version and release-note preparation;
 3. one publication command with its selected local checks and automated guards;
 4. declared deliverables, required build targets, and automation responsibilities;
 5. the successful-push completion point and separately reported delivery status;
   and
 6. failure handling, ambiguous-push recovery, and asynchronous delivery retries.
 Use copyable commands where practical. Keep optional diagnostics and consumer
 verification clearly optional. The procedure must not turn preparation work,
 ordinary change review, or post-publication investigation into additional
 release gates.
 ## Promptkit Release Configuration
 The release-note requirements were adopted on 2026-09-23 and licensing
 navigation on 2026-09-26. Apply them prospectively; previously published notes
 and tags retain their original records.
 Promptkit publishes source-only Go modules from main to origin on Gitea, using
 annotated stable SemVer tags. It has no binaries, hosted download pages, or
 asynchronous deliverables. The source commit is pushed through main before the
 tag. The [release procedure](../release.md) owns commands and recovery.
 The existing publication script requires Summary, Compatibility, Upgrade, and
 Changes headings beneath a title of `# Promptkit vMAJOR.MINOR.PATCH`. State
 “No action required” or “None” where appropriate. This retained local structure
 matches the automated release-note guard; changing it is separate work.
 The [publication script](../../scripts/release.sh) runs the
 [local checks](../../scripts/release-check.sh) once for the final committed
 candidate: race-enabled tests, vet, three offline consumer examples, tracked
 Go formatting, Markdown links, module/workspace hygiene, whitespace, and a
 credential-pattern scan. These protect concurrency, assembled library use,
 source distribution, and documentation integrity. A separate ordinary test run
 or standalone build is not an additional release gate. Candidate, tag, and
 synchronized-main checks remain automated. No CI or module-availability wait
 is required. Licensing footer URLs are preparation work, not a network gate.
 ## Catalog Profile Compatibility
@@ -51,96 +250,3 @@ migrations.
 Catalog adoption and release validation remain local and offline. They do not
 probe provider endpoints, request model lists, or make inference calls.
 ## Release Documentation
 Every new release must include `docs/releases/<version>.md` in the tagged
 source, using the complete tag as the filename. Its title contains Promptkit
 and that exact version. Use this structure:
 ```markdown
 # Promptkit vMAJOR.MINOR.PATCH
 This release ...
 ## Summary
 ## Compatibility
 ## Upgrade
 ## Changes
 ```
 State “No action required” or “None” where appropriate rather than omitting a
 section. Keep exact current contracts in their canonical documents and link
 to them. Update affected canonical documentation in the same candidate.
 These notes are historical records, not optional disposable guidance. Published
 release-note contents must not be replaced under the same version. Corrections
 belong in a subsequent release. Annotated-tag messages complement the checked-in
 note: generate the annotation from that note and the validated commit rather
 than maintaining a second summary.
 ## Validation And Publication
 The [publication script](../../scripts/release.sh) runs the
 [local checks](../../scripts/release-check.sh) once for the final candidate.
 Retain clean-candidate, synchronized-main, unused-version, module-hygiene,
 release-note structure, and tag-target checks. Publish only the selected tag
 ref. Changing the candidate requires fresh validation. No provider endpoint
 probes or inference calls are release checks.
 Release-note content and retirement of completed roadmaps are preparation
 responsibilities, not separate human sign-off gates. Preserve planned and
 deferred work and repair links. Ordinary change review covers unintended files,
 secrets, and private data; do not repeat it as a release-specific approval.
 A successful tag push to origin completes the release. Never wait for CI to
 finish or succeed. CI results, remote read-back, and Go module availability
 are informational follow-ups, not completion gates. An ambiguous push result
 requires confirming publication on origin, not waiting for CI.
 ## Immutability And Failure Recovery
 Never move, replace, recreate, or delete a published tag or replace published
 release contents. If validation fails before publication, correct the candidate,
 rerun the complete checks, and repeat the publication guards. Remove an
 unpublished local tag only after confirming it was not published.
 If publication or subsequent investigation reveals a defect, leave the
 published release intact. Correct the defect on main, select a new patch or
 other semantically appropriate version, write its matching release note, and
 repeat the complete procedure. If publication status is uncertain, inspect
 the authoritative remote before deciding whether a tag is unpublished; do not
 overwrite it to retry.
 Transient network, authentication, CI, or module-availability failures do not
 by themselves warrant a new version. Investigate separately and publish a
 corrective release only when published contents actually need changing.
 ## Policy Exceptions And Deliberate Scope
 This adoption follows the maintainer-approved lean workflow rather than every
 base-policy guard:
 - Collision checks concern origin, the authoritative publication destination,
  rather than every configured remote. Local and origin tag checks, synchronized
  main, and an explicit selected-ref push protect the actual release channel.
 - Automated local validation and publication-state checks replace manual
  mechanical inspections and separate human sign-offs. Ordinary change review,
  editorial responsibility for release notes, and roadmap housekeeping remain;
  repeating them as approvals would add friction without distinct protection.
 - Successful tag publication completes this source-only release. CI can be slow
  or unreliable, and module availability depends on external services. Neither
  is a completion gate. Local candidate validation and explicit tag-target
  checks protect publication; ambiguous push results are resolved against origin.
  Actual defects are corrected in a new release, never by replacing a tag.
 Ignored local files are not prohibited merely because they exist: they are not
 included in the tagged commit. The clean-candidate guard and ordinary review of
 tracked changes protect the published contents.
 The catalog profile provision preserves an already approved compatibility
 boundary; it does not extend volatility to backend definitions or runtime
 contracts. Further release-governance changes require deliberate approval.
--- a/docs/policy/testing.md
+++ b/docs/policy/testing.md
@@ -1,43 +1,32 @@
 # Testing Policy
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.3
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
 **Upstream Source:** [testing.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md)
 ## Purpose
 Our tests exist to make **incorrect changes expensive and correct changes cheap**.
-We do not optimize for test count, line coverage, exhaustive isolation, or the fewest possible tests. We optimize for sufficient confidence in important behavior while imposing as little unnecessary friction as possible on future development.
+We optimize for sufficient confidence in important behavior while minimizing friction on future development.
 ## Every test has a cost
-Testing is not an unqualified good. Every test imposes both an immediate cost and a continuing lifetime cost.
+Every test has an immediate and continuing cost: writing, review, execution,
-
+diagnosis, fixture maintenance, and updates when legitimate behavior changes.
-A test must be:
+Tests can also constrain refactoring, duplicate policy, and add failure noise.
 - written and reviewed;
 - understood by future maintainers and coding agents;
 - executed in maintainer-run validation;
 - diagnosed when it fails;
 - updated when legitimate behavior changes;
 - maintained as fixtures, APIs, and dependencies evolve; and
 - removed or rewritten when it becomes redundant, brittle, misleading, or obsolete.
 Tests also create cognitive and architectural friction. They can constrain refactoring, duplicate policy, slow feedback loops, add noise to failures, and cause harmless implementation changes to require unrelated edits across the suite.
 A test is warranted only when the confidence it provides justifies these costs.
-
+Evaluate that tradeoff at two levels:
 Apply this cost-benefit analysis at two levels:
 1. **Per test:** What realistic defect does this test detect, how consequential would that defect be, and is that protection worth the test's lifetime cost?
 2. **Across the suite:** Does this collection provide materially more confidence than a smaller, simpler suite would?
-The preferred test suite is a **lean suite that provides sufficient confidence in the risks that matter, without redundant or low-value tests**. We seek sufficient confidence with the least unnecessary testing friction, not the fewest possible tests.
+Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. Keep ordinary internal changes inexpensive.
-Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. They should not make ordinary internal changes needlessly expensive.
+Evaluate maintenance cost against the specific failure being protected. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
 The cost of a test is not a reason to omit testing by default. Do not cite maintenance cost abstractly. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
 ## Default testing style
@@ -51,6 +40,12 @@ Use a **classical/Detroit-style** approach:
 Examples of appropriate seams include clocks, randomness, subprocesses, remote APIs, object storage, email, and paid LLM calls.
 ## Promptkit Test Boundaries
 Promptkit is a library without a CLI or hosted CI. The execution requirements,
 facade test ownership, public error guidance, and offline consumer examples
 below tailor the standard to that boundary.
 ## Test execution requirements
 Promptkit currently uses maintainer-run validation rather than hosted CI.
@@ -110,7 +105,7 @@ Use each test type where it protects a distinct risk:
 ## What deserves tests
-Prioritize tests for:
+To the extent the following features are present in the application, prioritize tests for:
 1. Public and package-level contracts.
 2. Domain rules and important invariants.
@@ -118,17 +113,29 @@ Prioritize tests for:
 4. Failure handling, cancellation, retries, recovery, and partial success.
 5. Serialization, schemas, compatibility, and round trips.
 6. Previously observed or plausible regressions.
-7. Representative integration and consumer workflows.
+7. Representative integration and end-to-end workflows.
-A package-level contract is behavior relied upon by another package or major collaborator, not every observable detail of a package implementation.
+A package-level contract comprises behavior relied upon by another package or major collaborator.
-For behavior involving **data integrity, destructive operations, compatibility, security, concurrency, idempotency, or recovery**, presume that durable tests are required unless the behavior is already credibly protected at another layer.
+Choose tests for requested behavior and established contracts. Tests must not
 introduce new restrictions, guarantees, or threat scenarios merely because they
 could be asserted. Follow the [agent policy](agents.md) when deciding whether a
 behavior belongs to the contract; current implementation behavior alone is not
 sufficient authority.
 For established behavior involving **data integrity, destructive operations,
 compatibility, security, concurrency, idempotency, or recovery**, favor durable
 tests for realistic failures whose consequences warrant protection. Identify
 the failure and the existing contract it would violate. These categories call
 for attention, not an automatic test inventory or permission to strengthen the
 application's guarantees. Account for protection already provided at other layers.
 Do not add tests merely because a function, branch, or line exists. Do not add a test when the same meaningful risk is already adequately protected elsewhere.
 ## Choose the right test boundary
-Test through the narrowest stable boundary that expresses the behavior clearly.
+Choose the narrowest stable boundary that expresses the behavior clearly and
 provides durable confidence with minimal incidental coupling.
 This is often the package API, but it may instead be:
@@ -136,30 +143,15 @@ This is often the package API, but it may instead be:
 - a package-level operation when several internal collaborators jointly produce the behavior; or
 - a larger integration boundary when correctness emerges from interaction with a real dependency.
 Do not force all behavior through oversized consumer-workflow tests. Do not
 test every private helper merely because it exists. Choose the boundary that
 gives durable confidence with the least incidental coupling.
 ## Test behavior, not implementation
-A test should protect a decision, contract, or invariant—not memorialize the current implementation.
+A test should protect a selected decision, contract, or invariant.
-Before adding or retaining a test, ask:
+A test is suspect when it primarily detects changes to private constants or
 helpers, equivalent operation ordering, incidental formatting, equivalent
 algorithms, or internal structure that preserves behavior.
-> What realistic defect would this test catch?
+Behavioral tests should normally remain stable through internal refactoring that preserves the contract.
 A test is suspect when its main purpose is to detect that someone:
 - changed an internal constant;
 - renamed or split a private helper;
 - reordered equivalent internal operations;
 - changed incidental formatting;
 - replaced one correct algorithm with another; or
 - refactored internal object structure without changing behavior.
 Refactoring should normally require no test edits unless the refactored structure is itself part of the contract.
 A test can be factually correct and still have negative value. Accurately describing current behavior is not enough; the protected behavior must be important enough to justify the future friction.
 ## Expected effects of different changes
@@ -176,13 +168,13 @@ A test failing is not the same as a test needing to be edited. Many tests may co
 ## Separate mechanism from policy
-Configurable thresholds and defaults must not be duplicated throughout the test suite.
+Derive expectations from test-controlled configuration and relationships.
-The following fragments are illustrative rather than standalone Go programs.
+For this example, assume the selected contract rejects a request to start more
-Do not encode an internal concurrency limit indirectly:
+processes than a configured limit. Do not encode its production default indirectly:
 ```go
-// Production policy:
+// Production default:
 const maxConcurrency = 4
 // Brittle test:
@@ -200,37 +192,40 @@ require.NoError(t, runner.Start(limit))
 require.ErrorIs(t, runner.Start(limit+1), ErrTooMuchConcurrency)
 ```
-The test should prove:
+For this selected contract, the test should prove:
 - the configured limit is accepted; and
 - one beyond the configured limit is rejected.
 Rejection is not a general requirement for concurrency control. If the selected
 contract queues excess work or limits active workers while accepting larger
 batches, test that behavior instead. Do not add rejection or a configurable
 limit solely to reproduce this example.
 The production default should be tested exactly only when its literal value is itself a public, operational, safety, protocol, or compatibility requirement.
-Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior, not duplicated literals.
+Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior.
-For concurrency limits, test both kinds of behavior when relevant:
+For established concurrency limits, distinguish these behaviors where the contract requires them:
-1. **Configuration enforcement:** invalid or excessive requested values are handled correctly.
+1. **Configuration handling:** values are accepted or rejected according to the selected contract.
 2. **Runtime enforcement:** observed peak concurrency never exceeds the configured limit.
-Use a test-controlled limit and measure the behavior relative to that limit. Do not merely assert today's default value.
+Use a test-controlled limit and measure the behavior relative to that limit.
-## Avoid semantic duplication across layers
+## Assign each behavior a test owner
-Each behavior should have a clear test owner.
+Where these layers exist, assign ownership as follows:
 - Parser tests own parsing cases.
 - Validator tests own validation rules.
 - Domain tests own transformations and invariants.
- Boundary tests own external integration behavior.
+- Adapter tests own external integration behavior.
 - Orchestrator tests own coordination and failure propagation.
- Consumer-workflow tests prove that representative assembled library use
+- External-package root tests own the public Go facade contract.
-  works.
+- Consumer-workflow tests prove that representative assembled library use works.
-Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
+Give each layer its distinct responsibility and keep expectation updates localized to the contract being changed.
 Tests that are individually reasonable may still be collectively redundant. Evaluate the marginal value of each additional test in light of the protection already provided by the rest of the suite.
 ## Use test doubles deliberately
@@ -251,111 +246,78 @@ Mocks are appropriate when the contract includes facts such as:
 - an expensive API is called no more than once; or
 - a security audit event is emitted.
 Do not use mocks merely to isolate every object or reproduce the implementation's call graph.
 ## Go-specific guidance
-Use:
+Select techniques by behavior and risk:
 - table-driven tests for meaningful behavioral categories and boundaries;
 - `t.TempDir()` for real filesystem behavior;
 - `httptest.Server` for realistic HTTP interactions;
- fuzz tests for parsers, normalization, path handling, and broad input spaces;
+- fuzz tests when exploring broad input spaces, such as parsers or path handling, adds useful protection beyond representative cases;
 - golden files only when the complete output is intentionally stable;
 - integration tests where correctness depends on component interaction; and
- a small number of representative consumer-workflow tests.
+- a small number of representative end-to-end tests when assembled workflows expose meaningful risks not adequately covered at narrower boundaries.
-Avoid exact error-string assertions unless the wording is itself contractual. Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields.
+Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields. Use exact error-wording assertions only when the wording is contractual.
 At public API boundaries, prefer stable error identity, structured values, and
-the smallest semantic fragment needed to identify the failure. Do not snapshot
+the smallest semantic fragment needed to identify the failure. Use complete
-complete diagnostic wording unless it is contractual.
+diagnostic snapshots only when the wording is contractual.
-Golden-file updates must require an explicit local flag. Ordinary validation
+Golden-file updates must require an explicit local flag. Ordinary validation runs must never update golden files automatically, and reviewers must inspect the semantic diff before accepting an update.
 runs must never update golden files automatically, and maintainers must inspect
 the semantic diff before accepting an update.
-Keep tests readable and direct. Test helpers and fixture frameworks must earn their own maintenance cost; do not build elaborate test infrastructure for small or isolated needs.
+Keep tests readable and direct. Size test helpers and fixture frameworks to the maintenance benefit they provide.
 ## Coverage
-Coverage is a diagnostic, not a target.
+Use coverage to locate untested critical branches and unexpectedly weak packages. Evaluate test quality through meaningful behavioral protection and choose coverage according to risk.
-Use it to find untested critical branches and unexpectedly weak packages. Do not write low-value tests solely to increase a percentage, and do not infer test quality from coverage alone.
+Pure domain logic will often warrant higher coverage than facade wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
 Pure domain logic will often warrant higher coverage than facade wiring or
 external adapters. Uneven coverage is acceptable when it reflects risk.
 Increasing coverage is valuable only when the newly covered behavior protects a meaningful risk at an acceptable cost.
 ## Regression tests
 A bug fix should normally include a regression test that fails before the fix and passes afterward.
-Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant; do not preserve accidental implementation details from the original bug.
+Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant.
-Not every historical bug requires a permanent test. If the underlying design has made recurrence impossible, the test has become redundant, or a stronger invariant test now subsumes it, remove or consolidate it.
+Remove or consolidate a test when the underlying design has made recurrence impossible, its protection is redundant, or a stronger invariant test subsumes it.
 ## Deleting or rewriting tests
-Tests are maintained code, not permanent historical artifacts.
+Delete or rewrite tests when maintenance cost exceeds their continuing
-
+protective value.
 Delete or rewrite a test when its maintenance cost exceeds the confidence it provides.
 Strong candidates include tests that:
 - require updates after harmless internal changes;
- directly assert private constants without protecting a real contract;
+- assert incidental private constants or snapshot large amounts of incidental output;
 - duplicate the same policy across several layers;
 - verify mock choreography rather than outcomes;
- snapshot large amounts of incidental output;
+- duplicate policy across layers, retest trivial helpers covered by package
- test trivial private helpers already exercised through stable package behavior;
+  behavior, or protect risks covered more effectively elsewhere;
 - protect risks already covered more effectively elsewhere;
 - are flaky, misleading, obsolete, or disproportionately expensive to diagnose; or
 - no longer correspond to a plausible failure mode.
-Several brittle tests may encode one genuine requirement. Replace them with one durable behavior-level or invariant test rather than preserving all of them.
+Several brittle tests may encode one genuine requirement. Consolidate them into one durable behavior-level or invariant test.
 Deleting a low-value test can improve the quality of the suite by reducing noise, maintenance burden, and friction around legitimate change.
 ## Reviewing a proposed test
-Use the following questions when the value, boundary, or durability of a proposed test is not self-evident. Significant test additions should be reviewable against them, but written answers are not required for every routine test.
+Use the following questions when a proposed test needs closer evaluation. Significant test additions should be reviewable against them; written answers are optional for routine tests.
-1. What realistic defect would it catch?
+1. Which requested behavior or established contract does it protect, and what realistic defect would violate it?
-2. How likely is that defect?
+2. How likely and consequential is that defect, and is it already protected elsewhere?
-3. How consequential would it be?
+3. What is the narrowest stable boundary that can test it clearly?
-4. Is the behavior already protected elsewhere?
+4. Would a correct internal refactor or a change to an incidental default require test edits?
-5. At which layer should this behavior be owned?
+5. Does its confidence justify its maintenance, execution, and diagnostic cost, or would a smaller test suffice?
 6. Does the test assert a durable contract or an incidental implementation detail?
 7. Could the implementation be refactored without changing the behavior and without editing this test?
 8. What should cause this test to fail?
 9. What legitimate changes should not cause this test to fail?
 10. What ongoing maintenance, execution, and diagnostic cost will the test impose?
 11. Is there a smaller or more direct test that protects the same risk?
 Do not add the test when its expected lifetime cost exceeds its expected protective value.
 When deciding not to test plausible behavior, record or be able to explain why the risk is low, already protected, obvious, reversible, or cheaper to detect elsewhere.
 ## Definition of sufficient
 A test suite is sufficient when:
- important contracts and invariants are protected;
+- important requested behavior and established contracts are protected against realistic, consequential failures;
- meaningful boundaries and failure modes are exercised;
+- boundaries and component interactions have coverage where they introduce meaningful risks not protected elsewhere;
- realistic and consequential regressions are credibly protected against silent recurrence;
+- failures provide useful, distinct signals;
- behavior involving data integrity, destructive operations, compatibility, security, concurrency, idempotency, and recovery is credibly protected;
+- tests usually remain stable through legitimate internal changes; and
 - important external boundaries have realistic integration coverage;
 - representative complete workflows are tested;
 - failures provide useful signal rather than redundant noise;
 - legitimate internal changes usually do not require test edits; and
 - additional tests would mostly repeat existing protection or preserve inconsequential implementation details.
-Sufficiency is a risk judgment, not a coverage percentage or test count.
+Reassess sufficiency as the application, its users, and the consequences of
-Reassess it as the library, its consumers, and the consequences of failure
+failure evolve.
 evolve.
 The governing rule is:
 > Test heavily where failure is consequential, subtle, or difficult to detect after the fact. Test lightly where failure is obvious, reversible, and inexpensive—and retain no test whose lifetime cost exceeds the confidence it provides.
--- a/docs/release.md
+++ b/docs/release.md
@@ -15,6 +15,21 @@ compatibility impact and consumer actions and update affected canonical docs.
 For catalog updates, record selected catalog versions and any consumer action,
 linking to the catalog policy rather than repeating its contracts.
 Follow the [OSS policy](policy/oss.md) when preparing licensing and attribution
 changes. Each new note must end with the following navigation, replacing
 `vMAJOR.MINOR.PATCH` with the selected release tag:
 ```markdown
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit/src/tag/vMAJOR.MINOR.PATCH/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/tag/vMAJOR.MINOR.PATCH/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/promptkit/src/tag/vMAJOR.MINOR.PATCH/docs/oss/attribution.md)
 ```
 Check these file paths against the candidate; a future tag need not resolve
 remotely during preparation. The annotated tag derives from this same note,
 including its footer. Promptkit publishes no separate hosted release body or
 download page. If such a channel is deliberately introduced, reuse the note
 and preserve its footer. No extra network checks, artifacts, or approval gates
 are introduced, and published notes are not retrofitted.
 Retire completed roadmaps, preserving planned or deferred work and repairing
 links. This is housekeeping, not a separate approval gate. Review changes
 through the ordinary development workflow, commit them, and push main to
--- a/docs/releases/v0.11.0.md
+++ b/docs/releases/v0.11.0.md
@@ -29,7 +29,7 @@ they are not a complete billing ledger. See the
 Promptkit is now licensed under LGPL-3.0-or-later. Review the
 [license summary](../../README.md#license), [LGPL text](../../LICENSE), and
-[accompanying GPL text](../../COPYING) before adoption or distribution.
+[accompanying GPL text](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/COPYING) before adoption or distribution.
 Previously published releases and dependency licenses are unchanged.
 ## Upgrade
--- a/docs/releases/v0.11.1.md
+++ b/docs/releases/v0.11.1.md
@@ -0,0 +1,43 @@
 # Promptkit v0.11.1
 This patch updates the maintained catalogs to MIT-licensed releases and
 improves licensing documentation.
 ## Summary
 Both OpenRouter and Rakestrawhome catalogs now use `v2.20260926.0`. These
 catalog releases change licensing and documentation only; their profiles,
 backend definitions, and Go code are unchanged.
 ## Compatibility
 No public API, runtime behavior, or profile changes are introduced.
 Promptkit remains LGPL-3.0-or-later; the catalogs are now MIT-licensed.
 See the [project grant](../../COPYRIGHT),
 [component attribution](../oss/attribution.md), and
 [catalog compatibility policy](../policy/release.md#catalog-profile-compatibility).
 ## Upgrade
 Update the module dependency:
 ```sh
 go get gitea.maximumdirect.net/eric/promptkit@v0.11.1
 ```
 No code or configuration migration is required from v0.11.0.
 Consumers upgrading from earlier versions should also read the
 [v0.11.0 migration guide](v0.11.0.md).
 ## Changes
 - Adopt the MIT-licensed catalog releases and update inventory links.
 - Add centralized attribution and dependency license texts.
 - Separate the project grant into COPYRIGHT and consolidate the LGPLv3 and
  incorporated GPLv3 texts in LICENSE, replacing the separate COPYING file.
 - Align documentation ownership and future release navigation with the
  [OSS policy](../policy/oss.md), without adding release gates.
 - Repair the historical v0.11.0 GPL-text link and retire the completed
  licensing roadmap.
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/oss/attribution.md)
--- a/docs/releases/v0.11.2.md
+++ b/docs/releases/v0.11.2.md
@@ -0,0 +1,38 @@
 # Promptkit v0.11.2
 This patch aligns repository policies with the current standard and clarifies
 licensing and attribution for the copied policy documents.
 ## Summary
 The update adds policy provenance, selective contributor reading guidance, and
 consistent upstream policy language while preserving Promptkit-specific rules.
 ## Compatibility
 No public API, runtime behavior, dependency, or catalog changes are introduced.
 Promptkit remains LGPL-3.0-or-later. The [project grant](../../COPYRIGHT)
 identifies the separate CC-BY-SA-4.0 scope for copied or adapted policy material;
 the [attribution notices](../oss/attribution.md) identify the affected documents.
 The existing release checks and successful-tag-push completion point are unchanged.
 ## Upgrade
 ```sh
 go get gitea.maximumdirect.net/eric/promptkit@v0.11.2
 ```
 No code or configuration migration is required from v0.11.1.
 ## Changes
 - Align adopted policies with Standard Repository Policies while retaining
  library-specific requirements and deliberate local decisions.
 - Add per-document upstream source links and the
  [policy-set provenance document](../policy/meta.md).
 - Add selective policy reading to the [contributor guide](../development.md)
  and update agent orientation.
 - Standardize factual attribution entries and identify copied-policy licensing.
 - Retire the completed policy-alignment roadmap.
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/oss/attribution.md)
--- a/go.mod
+++ b/go.mod
@@ -3,8 +3,8 @@ module gitea.maximumdirect.net/eric/promptkit
 go 1.25.5
 require (
-	gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1
+	gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0
-	gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0
+	gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0
 	github.com/santhosh-tekuri/jsonschema/v6 v6.0.2
 	gopkg.in/yaml.v3 v3.0.1
 )
--- a/go.sum
+++ b/go.sum
@@ -1,7 +1,7 @@
-gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1 h1:S2/Q/JDE+m8Ca3pDhAjVbfYrdlEhs9blj0STgNopHo0=
+gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 h1:wdab+R+lgMZxzYwhbAuCrW7zdSQ1cW9ovBR6UzLmZR4=
-gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1/go.mod h1:a3VBbh9oaGXD6ruxhtwHj+AWW6DY/SSyby1QtMmYSUo=
+gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0/go.mod h1:a3VBbh9oaGXD6ruxhtwHj+AWW6DY/SSyby1QtMmYSUo=
-gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0 h1:Y0EXc3eh12eKW2NrOviVqdk3oBo6UUjopt1YAa1B3Oc=
+gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0 h1:baCCIB6Ee5t0S4Zc++NTBIPcJEv5UPS6DlSrpZfykwg=
-gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
+gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
 github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI=
 github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8=
 github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ=
Author	SHA1	Message	Date
Eric Rakestraw	12d6d80024	Prepare the v0.11.2 release	2026-09-28 00:02:23 +00:00
Eric Rakestraw	d8147cac49	Remove the policy adoption narrative	2026-09-28 00:01:57 +00:00
Eric Rakestraw	a16c2a38d6	Align policies with the standard and record their provenance	2026-09-27 21:18:11 +00:00
Eric Rakestraw	843d07b636	Plan standard policy alignment	2026-09-27 21:10:12 +00:00
Eric Rakestraw	dc6fd2752d	Align OSS attribution notices to the house standard format	2026-09-27 13:40:57 +00:00
Eric Rakestraw	15e4067954	Prepare the v0.11.1 release	2026-09-26 21:48:47 +00:00
Eric Rakestraw	6e34fb9de5	Align licensing documentation and adopt MIT catalogs	2026-09-26 21:44:52 +00:00
Eric Rakestraw	5843ceef82	Plan licensing documentation and policy alignment	2026-09-26 20:47:29 +00:00
Eric Rakestraw	1cd0c611f2	Align the COPYRIGHT and LICENSE files to the house standard	2026-09-26 14:57:33 -05:00
Eric Rakestraw	6ed582f4b5	Align licensing documentation to LGPL-3.0-or-later	2026-09-26 14:07:53 -05:00