Prepare Scriptorium v0.15.0 release notes

AGENTS.md

@@ -1,4 +1,6 @@
-Please review `docs/development.md` for initial orientation in this repository and follow its task-specific reading guide.
+Start with `docs/development.md` for orientation and use its policy 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
-implementing changes to this repository.
+Read and follow `docs/policy/agents.md` before recommending, planning, or
+implementing repository changes.

COPYRIGHT

@@ -0,0 +1,23 @@
+Scriptorium
+
+Copyright (C) 2026 Eric Rakestraw
+
+SPDX-License-Identifier: GPL-3.0-or-later
+
+Scriptorium 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.
+
+The GNU General Public License version 3 is provided in LICENSE.
+
+Scriptorium 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.
+
+Third-party code and assets are subject to their respective license terms.
+
+Policy documents 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.

LICENSE

@@ -1,11 +1,674 @@
-Copyright (c) 2026 Eric Rakestraw. 
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
 
-Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+ 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.
 
-1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+                            Preamble
 
-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.
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
 
-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.
+  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.
 
-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.
+  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>.

README.md

@@ -6,7 +6,7 @@ OpenAI-compatible model endpoints, and returns generated output with validation
 metadata.
 
 The application uses
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/)
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/)
 for prompt, profile, schema, preparation, generation, and validation behavior.
 Scriptorium owns executable configuration, CLI and HTTP mapping, process
 behavior, output presentation, and HTTP artifact-containment policy.
@@ -39,8 +39,8 @@ a model. For complete invocation and output behavior, see the
 - [Migration from the former Go package](docs/consumers/migrating-to-promptkit.md)
 - [Subprocess integration](docs/integrations/subprocess.md)
 - [Architecture policy](docs/policy/architecture.md)
-- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
-- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
+- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
 
 ## Examples
 
@@ -52,6 +52,6 @@ a model. For complete invocation and output behavior, see the
 - [Render script](examples/render-markdown-summary.sh)
 - [HTTP request](examples/http-run.json)
 
-Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
+Scriptorium is licensed under the [GPL v3.0 or later](COPYRIGHT).
 
 [Open Source attribution notices](docs/oss/attribution.md) are available.

docs/api.md

@@ -68,11 +68,11 @@ The optional `model` object accepts `endpoint`, `model`, `temperature`,
 `max_tokens`, `top_p`, `timeout_seconds`, `service_tier`,
 `reasoning_effort`, `api_key_env`, and `extra_params`. Numeric ranges and
 framework credential semantics are defined by the
-[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
 Explicit zero values for the numeric fields are overrides; zero
 `timeout_seconds` disables the per-attempt generation deadline only, retaining the
 request context and configured transport cap. The timeout layers are defined in
-the [Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
+the [Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
 Each built-in transient retry gets a fresh generation timeout; the caller's
 request context remains the outer cancellation boundary.
 

docs/cli.md

@@ -90,7 +90,7 @@ only; the caller context and configured transport cap remain active. CLI
 durations are converted to whole seconds by truncation toward zero, so any
 duration whose absolute value is below one second becomes an explicit
 zero-second override. The timeout layers are defined in the
-[Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
+[Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
 With the built-in client, each transient retry gets a fresh generation timeout;
 this flag does not limit the complete run.
 `--run-timeout` keeps subsecond precision and starts immediately before engine

docs/config.md

@@ -3,7 +3,7 @@
 This is the canonical reference for Scriptorium application settings. Prompt,
 profile, schema, execution-setting, built-in profile, and framework credential
 semantics are defined by the
-[Promptkit v0.11.0 format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit v0.11.2 format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
 For command syntax, see the [CLI reference](cli.md); for HTTP request shapes and
 outcomes, see the [HTTP API reference](api.md).
 
@@ -26,7 +26,7 @@ The maintained [minimal configuration](../examples/config.yml),
 
 ## Application Configuration File
 
-Configuration is decoded by ConfigKit v0.4.0 as strict YAML. Unknown fields,
+Configuration is decoded by ConfigKit v0.4.2 as strict YAML. Unknown fields,
 empty files, multiple YAML documents, and YAML aliases/anchors are rejected.
 An explicit empty string is a value: it clears a file-provided optional path
 or, for required `prompt_dir`, fails the command's prerequisite. A scalar
@@ -152,7 +152,7 @@ parse those framework file formats.
   contracts.
 
 See the
-[tagged Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
+[tagged Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
 for all of those definitions. The files under
 [`examples/prompts`](../examples/prompts/),
 [`examples/profiles`](../examples/profiles/), and
@@ -195,7 +195,7 @@ client retains its own retry behavior. The tagged integration contract owns
 eligibility and timing.
 
 Promptkit's
-[OpenAI-compatible integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
+[OpenAI-compatible integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
 defines outbound authentication, provider request mapping, transport limits,
 and timeout layering.
 
@@ -204,4 +204,4 @@ and timeout layering.
 - [CLI reference](cli.md)
 - [HTTP API reference](api.md)
 - [Operations guide](operations.md)
-- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
+- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)

docs/consumers/api.md

@@ -14,7 +14,7 @@ and the HTTP service according to the boundary your application needs.
 
 Go applications that need an in-process prompt framework should import
 Promptkit directly. The tagged
-[Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+[Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
 owns that interface; Scriptorium does not provide a Go library package.
 Consumers arriving from the former Scriptorium Go API should follow the
 [migration guide](migrating-to-promptkit.md).
@@ -35,4 +35,4 @@ Scriptorium does not persist run state. A retry can produce different output
 and can incur another provider request. CLI exits belong to the
 [CLI reference](../cli.md), HTTP status behavior belongs to the
 [HTTP API reference](../api.md), and framework semantics belong to
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).

docs/consumers/migrating-to-promptkit.md

@@ -4,7 +4,7 @@
 
 Scriptorium `v0.11.1` at
 `gitea.maximumdirect.net/eric/scriptorium` is the final release that provides
-the former in-process Go framework. Promptkit `v0.11.0` at
+the former in-process Go framework. Promptkit `v0.11.1` at
 `gitea.maximumdirect.net/eric/promptkit` is the destination for that framework
 API. Scriptorium `v0.12.0` and later provide the CLI and HTTP application only.
 
@@ -19,7 +19,7 @@ Start from a clean consumer checkout and review the pending diff before
 committing it. Add the published Promptkit module:
 
 ```sh
-go get gitea.maximumdirect.net/eric/promptkit@v0.11.0
+go get gitea.maximumdirect.net/eric/promptkit@v0.11.1
 ```
 
 For an ordinary consumer that imports the former root package under its
@@ -51,14 +51,14 @@ go mod tidy
 go test ./...
 ```
 
-Confirm that `go.mod` selects Promptkit `v0.11.0` and that no Go file imports
+Confirm that `go.mod` selects Promptkit `v0.11.1` and that no Go file imports
 the former Scriptorium package:
 
 ```sh
 test "$(
   go list -m -f '{{.Path}}@{{.Version}}' \
     gitea.maximumdirect.net/eric/promptkit
-)" = 'gitea.maximumdirect.net/eric/promptkit@v0.11.0'
+)" = 'gitea.maximumdirect.net/eric/promptkit@v0.11.1'
 if git grep -n \
   'gitea.maximumdirect.net/eric/scriptorium' \
   -- '*.go'
@@ -73,20 +73,20 @@ fi
 Promptkit preserves the established engine, request, result, profile,
 source-option, model-client, artifact, validation-value, and public-error
 shapes where practical. Exact declarations and current behavior belong to the
-tagged [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+tagged [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md)
 and Go source.
 
 Promptkit also includes migration-relevant public contracts that were not in
 Scriptorium `v0.11.1`:
 
-- [`WithArtifactReader`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/engine.go#L169-L174)
+- [`WithArtifactReader`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/engine.go#L169-L174)
   and the
-  [`ArtifactReader` declaration](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/types.go#L315)
+  [`ArtifactReader` declaration](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/types.go#L315)
   provide the artifact-reading extension described by the tagged
-  [extension-interface guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md#extension-interfaces).
-- [`ErrProfileRequired` and `ErrAPIKeyEnvMissing`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/engine.go#L33-L48)
+  [extension-interface guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md#extension-interfaces).
+- [`ErrProfileRequired` and `ErrAPIKeyEnvMissing`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/engine.go#L33-L48)
   provide the specific identities described by the tagged
-  [error guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md#handle-errors).
+  [error guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md#handle-errors).
 
 Use those tagged owners for exact signatures, wrapping guarantees, and
 extension behavior.

docs/development.md

@@ -2,23 +2,39 @@
 
 This is the contributor entry point for Scriptorium. Scriptorium is an
 application that consumes the public
-[Promptkit v0.11.0 package](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md);
+[Promptkit v0.11.2 package](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md);
 framework implementation work belongs in Promptkit. Application configuration
-uses ConfigKit v0.4.0; keep Scriptorium's schema and source selection local.
+uses ConfigKit v0.4.2; keep Scriptorium's schema and source selection local.
 
 ## Initial Orientation
 
 Before recommending, planning, or implementing work:
 
-1. read the [agent policy](policy/agents.md);
-2. inspect the working tree and preserve unrelated changes;
-3. read the [architecture policy](policy/architecture.md);
-4. follow the task-specific contracts and internal documents below; and
-5. inspect the relevant implementation and tests before changing them.
+1. inspect the working tree and preserve unrelated changes;
+2. use the policy and task-specific reading guides below; and
+3. inspect the relevant implementation and tests before changing them.
 
-Also read the [documentation policy](policy/documentation.md) before changing
-documentation and the [testing policy](policy/testing.md) before changing
-tests.
+## Policy Reading Guide
+
+| Policy | Read before… |
+| --- | --- |
+| [Policy set provenance](policy/meta.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
+| [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
+| [Architecture](policy/architecture.md) | Planning or changing application code or its structure. |
+| [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
+| [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
+| [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
+| [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |
+
+- 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
 
@@ -29,13 +45,13 @@ tests.
 | HTTP routes, DTOs, limits, status mapping, or artifact policy | [HTTP API contract](api.md), [adapter internals](internal/adapters.md), and [source internals](internal/sources.md) |
 | Application configuration or precedence | [Configuration contract](config.md), [adapter internals](internal/adapters.md), [source internals](internal/sources.md), and `internal/config` definition/load tests |
 | Prepared-run presentation | [CLI contract](cli.md), [adapter internals](internal/adapters.md), and `internal/format` |
-| Prompt, profile, schema, generation, or validation semantics | [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md) and the [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md) |
-| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md) |
+| Prompt, profile, schema, generation, or validation semantics | [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md) and the [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md) |
+| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md) |
 | Subprocess behavior | [Subprocess integration](integrations/subprocess.md) and [CLI contract](cli.md) |
 | Runtime operation or recovery | [Operations](operations.md) |
 | Dependencies, copied assets, or attribution | The [OSS policy](policy/oss.md), [component attributions](oss/attribution.md), and [architecture policy](policy/architecture.md) |
 | Release documentation, packaging, or publication | The [release policy](policy/release.md), [OSS policy](policy/oss.md), [release procedure](release.md), [hosted release workflow](../.woodpecker/release.yml), and [architecture policy](policy/architecture.md) |
-| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md), and the related files under `examples/` |
+| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md), and the related files under `examples/` |
 | Architecture decisions or future work | The [documentation policy](policy/documentation.md), relevant accepted ADRs, and relevant roadmap documents |
 
 Cross-project changes land and release in Promptkit before Scriptorium adopts

docs/internal/adapters.md

@@ -9,7 +9,7 @@ own IO and presentation mechanics, not framework decisions.
 External contracts are canonical in the [CLI reference](../cli.md) and
 [HTTP API reference](../api.md). Promptkit's public engine contract is
 described by its tagged
-[Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md).
+[Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md).
 
 ## Components And Collaborators
 

docs/internal/overview.md

@@ -15,5 +15,5 @@ public behavior belongs in the linked contracts.
 | `internal/report` | Projects one terminal Promptkit observation into Scriptorium-owned execution metadata. | [adapter internals](adapters.md) |
 
 Framework implementation packages are provided by
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
 and are not part of this repository.

docs/internal/sources.md

@@ -5,7 +5,7 @@
 This document covers Scriptorium-owned source locations and the restricted HTTP
 artifact reader. Prompt, profile, schema, and ordinary artifact semantics are
 owned by the tagged
-[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
 
 ## Application Source Locations
 

docs/operations.md

@@ -9,7 +9,7 @@ fields, or HTTP wire behavior.
 - [CLI reference](cli.md): commands, output destinations, and exit codes.
 - [Configuration reference](config.md): application settings, source
   locations, defaults, and credential mapping.
-- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md):
+- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md):
   prompt, profile, schema, execution-setting, and framework credential
   contracts.
 - [HTTP API reference](api.md): route, request/response schema, status codes,
@@ -150,7 +150,7 @@ setting and then Promptkit's default, while explicit zero disables additional
 attempts. Existing generation timeouts apply
 per attempt, while the caller context covers the complete operation. Provider
 `Retry-After` timing can exceed Promptkit's ordinary backoff cap; consult the
-[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
+[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
 for details.
 
 CLI `run` can set a [whole-run deadline](cli.md) when total execution time must

docs/oss/attribution.md

@@ -1,91 +1,110 @@
-# Open-Source Attribution
+# Open Source Attribution Notices
 
-Scriptorium's own terms are in the repository [LICENSE](../../LICENSE).
-The [OSS policy](../policy/oss.md) governs these entries. Dependency versions
-are recorded in [go.mod](../../go.mod) and [go.sum](../../go.sum); source and
-notice links below identify the exact commits for the selected versions.
+## Standard Repository Policies
+
+Material: `docs/policy/oss.md`, `docs/policy/meta.md`,
+`docs/policy/agents.md`, `docs/policy/documentation.md`,
+`docs/policy/architecture.md`, `docs/policy/testing.md`,
+`docs/policy/release.md`, `AGENTS.md`, and the
+Policy Reading Guide section of `docs/development.md`, adapted for this
+repository.
+
+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
 
+Selected module: `gitea.maximumdirect.net/eric/promptkit` at `v0.11.2`.
+
 Copyright (C) 2026 Eric Rakestraw
 
 SPDX-License-Identifier: LGPL-3.0-or-later
 
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
-[GPL v3 companion](licenses/GPL-3.0.txt) |
-[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d/LICENSE)
+License and notices: [LGPL 3.0](licenses/LGPL-3.0.txt) |
+[GPL 3.0](licenses/GPL-3.0.txt) |
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2/COPYRIGHT) |
+[LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2/LICENSE).
 
-Source: [Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d)
+[Source](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2).
 
 ## ConfigKit
 
-Upstream copyright statement: no project-specific statement is present in the
-selected module; the FSF copyright in its license text belongs to that license
-document and is not substituted for a project notice.
+Selected module: `gitea.maximumdirect.net/eric/ConfigKit` at `v0.4.2`.
 
-SPDX-License-Identifier: LGPL-3.0-only
+Copyright (C) 2026 Eric Rakestraw
 
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
-[GPL v3 companion](licenses/GPL-3.0.txt) |
-[upstream LICENSE](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/e6ced0d3d1194b58e0b3dc8970089471ba175258/LICENSE)
+SPDX-License-Identifier: LGPL-3.0-or-later
 
-Source: [ConfigKit v0.4.0](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/e6ced0d3d1194b58e0b3dc8970089471ba175258)
+License and notices: [LGPL 3.0](licenses/LGPL-3.0.txt) |
+[GPL 3.0](licenses/GPL-3.0.txt) |
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f/COPYRIGHT) |
+[LICENSE](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f/LICENSE).
+
+[Source](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f).
 
 ## Promptkit OpenRouter Catalog
 
-Upstream copyright statement: no project-specific statement is present in the
-selected module. The linked upstream README records the profile assets'
-Promptkit origin and the copyright holder's deliberate relicensing.
+Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2` at `v2.20260926.0`.
 
-SPDX-License-Identifier: LGPL-3.0-only
+Copyright (C) 2026 Eric Rakestraw
 
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
-[GPL v3 companion](licenses/GPL-3.0.txt) |
-[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/LICENSE) |
-[asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/README.md)
+SPDX-License-Identifier: MIT
 
-Source: [OpenRouter catalog v2.20260922.1](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab)
+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
 
-Upstream copyright statement: no project-specific statement is present in the
-selected module. The linked upstream README records the profile asset's
-Promptkit origin and the copyright holder's deliberate relicensing.
+Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2` at `v2.20260926.0`.
 
-SPDX-License-Identifier: LGPL-3.0-only
+Copyright (C) 2026 Eric Rakestraw
 
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
-[GPL v3 companion](licenses/GPL-3.0.txt) |
-[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/LICENSE) |
-[asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/README.md)
+SPDX-License-Identifier: MIT
 
-Source: [Rakestrawhome catalog v2.20260922.0](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226)
+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/v6
 
-Upstream copyright statement: no project-specific statement is present in the
-selected module; no substitute statement is inferred here.
+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) |
-[upstream LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE)
+[LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE).
 
-Source: [jsonschema/v6 v6.0.2](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71)
+[Source](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71).
 
 ## golang.org/x/text
 
+Selected module: `golang.org/x/text` at `v0.14.0`.
+
 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) |
-[upstream LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE)
+[LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE).
 
-Source: [golang.org/x/text v0.14.0](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353)
+[Source](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353).
 
 ## gopkg.in/yaml.v3
 
+Selected module: `gopkg.in/yaml.v3` at `v3.0.1`.
+
 Copyright (c) 2006-2010 Kirill Simonov
 
 Copyright (c) 2006-2011 Kirill Simonov
@@ -96,18 +115,17 @@ Copyright 2011-2016 Canonical Ltd.
 
 SPDX-License-Identifier: MIT AND Apache-2.0
 
-The upstream LICENSE assigns MIT to files ported from libyaml and Apache 2.0
-to the remaining files; these are file-specific terms, not alternatives.
-
 License and notices: [MIT](licenses/MIT.txt) |
 [Apache 2.0](licenses/Apache-2.0.txt) |
-[upstream LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
-[upstream NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE)
+[LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
+[NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE).
 
-Source: [gopkg.in/yaml.v3 v3.0.1](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51)
+[Source](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51).
 
 ## go.yaml.in/yaml/v4
 
+Selected module: `go.yaml.in/yaml/v4` at `v4.0.0-rc.6`.
+
 Copyright 2006-2010 Kirill Simonov
 
 Copyright 2011-2019 Canonical Ltd
@@ -116,12 +134,9 @@ Copyright 2025 The go-yaml Project Contributors
 
 SPDX-License-Identifier: MIT AND Apache-2.0
 
-The upstream NOTICE assigns MIT to files ported from libyaml and Apache 2.0
-to the remaining files; these are file-specific terms, not alternatives.
-
 License and notices: [MIT](licenses/MIT.txt) |
 [Apache 2.0](licenses/Apache-2.0.txt) |
-[upstream LICENSE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/LICENSE) |
-[upstream NOTICE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/NOTICE)
+[LICENSE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/LICENSE) |
+[NOTICE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/NOTICE).
 
-Source: [go.yaml.in/yaml/v4 v4.0.0-rc.6](https://github.com/yaml/go-yaml/tree/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125)
+[Source](https://github.com/yaml/go-yaml/tree/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125).

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.

docs/policy/agents.md

@@ -1,12 +1,14 @@
 # Agent Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md
 
 ## Purpose
 
-Agents working in this repository must read and adhere to the following house rules.
+Agents must read and follow these rules.
 
 ## Implementation Discipline
 
@@ -43,15 +45,15 @@ unless that behavior was expressly selected as part of the contract.
 
 ## 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:
 
@@ -59,10 +61,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
-   staged or unstaged work.
-4. Review `git diff --staged` and run appropriate checks for the change. Do not
-   repeat checks already passed for unchanged content merely to create a commit.
+   only when every included change belongs to that unit. Preserve unrelated
+   staged and unstaged work.
+4. Review `git diff --staged` and run appropriate checks for the change. Reuse
+   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.

docs/policy/architecture.md

@@ -1,147 +1,110 @@
 # Architecture Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md
 
 ## Purpose And Ownership
 
-This policy defines Scriptorium's purpose, responsibility and dependency
-boundaries, established invariants, and non-goals. Concrete component inventory
-and implementation mechanics belong in [internal documentation](../internal/overview.md);
-public behavior belongs in its canonical contracts.
+The adopted policy defines the application's purpose and the architectural
+constraints contributors must follow. It owns system boundaries, responsibility
+and dependency rules, established invariants, and explicit non-goals.
 
-Adopted constraints govern future development without implying that every
-capability they could govern exists or is planned. Keep proposed structure and
-implementation status in roadmaps, and decision rationale in ADRs. Acceptance
-of a decision is not proof of implementation. Do not turn incidental choices
-into architectural invariants.
+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.
 
-## System Shape
+## Architectural Approach
 
-Scriptorium is an executable application with four command entry paths: CLI
-`run`, CLI `render`, CLI `inspect`, and the HTTP service started by `serve`.
-The `inspect` command has prompt and profile modes. Scriptorium does not expose
-a reusable root Go package.
+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.
 
-The application consumes
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
-through its supported root package. Promptkit owns prompt execution,
-preparation, source formats, built-in profiles, model-client behavior, and
-validation. Scriptorium owns application configuration, executable adapters,
-prepared-run and definition-inspection presentation, process behavior, and HTTP
-deployment 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.
 
-Scriptorium also consumes ConfigKit v0.4.0 for application configuration
-decoding, resolution, and validation flow. Scriptorium owns its application
-schema, defaults, normalization, validation rules, source selection, and CLI
-flag mapping; ConfigKit does not own Promptkit framework sources or HTTP
-artifact containment.
+## Adopted Constraints And Implemented Structure
 
-The concrete package inventory is maintained in the
-[internal overview](../internal/overview.md).
+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.
 
-As established by [ADR 0004](../adr/0004-definition-boundary.md), Scriptorium
-aims to support the complete set of features in valid Promptkit prompt and
-profile definitions for its selected upstream version. Promptkit remains the
-canonical parser and validator. Library-only features are considered
-individually against the simple predefined-prompt execution model.
+Constraints must reflect deliberately selected requirements and decisions.
+Do not promote incidental implementation choices into architectural invariants.
 
-Maintain adapter boundaries with proportionate, idiomatic code. This approach
-does not require an interface for every type, additional wrappers, or a fixed
-directory tree for integrations that do not exist.
+## Scriptorium's Purpose And System Shape
 
-## Dependency Direction
+Scriptorium is an executable application with CLI `run`, `render`,
+`inspect`, and `config` command families and an HTTP service started by
+`serve`. It offers simple, request-independent execution of predefined
+prompts, not a reusable Scriptorium root Go API or a workflow framework.
+The [internal overview](../internal/overview.md) owns the concrete package
+inventory; [adapter internals](../internal/adapters.md) and
+[source internals](../internal/sources.md) own implementation mechanics.
 
-```text
-cmd/scriptorium
-        |
-        v
-CLI and HTTP adapters, configuration, defaults, and formatting
-        |
-        v
-Promptkit (execution) and ConfigKit (application configuration)
-```
+## Framework And Application Boundaries
 
-- Retained application packages may import Promptkit's root package.
-- They must not import Promptkit `internal` packages.
-- They must not import Promptkit catalog modules directly.
-- They must not import the removed Scriptorium root facade or recreate former
-  framework package families.
-- Adapter-owned interfaces use Promptkit public values when a consumer-side
-  substitution boundary is needed.
-- Scriptorium passes omitted framework settings as zero values so Promptkit
-  applies its own defaults.
+Scriptorium consumes
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
+through its supported public root package. Promptkit owns prompt execution,
+preparation, prompt and profile formats, built-in profiles, model-client
+behavior, validation, and framework defaults. Scriptorium owns application
+configuration, executable CLI and HTTP adapters, prepared-run and
+definition-inspection presentation, process behavior, and HTTP deployment
+policy. The [format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
+and [outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
+remain Promptkit's contracts.
 
-The repository architecture guard enforces these import and removal
-invariants.
+Scriptorium uses ConfigKit v0.4.2 for strict application YAML decoding,
+resolution, and validation flow. Scriptorium retains its application schema,
+defaults, normalization, validation rules, source selection, and CLI override
+mapping. ConfigKit does not own Promptkit framework sources or HTTP artifact
+containment. The [configuration contract](../config.md) owns externally
+observable configuration behavior.
 
-Cross-project changes land and release in Promptkit before Scriptorium adopts
-the tagged dependency. Do not commit Go workspaces, local replacements,
-vendored Promptkit implementation, or unpublished dependency assumptions.
+Application code may import Promptkit's public root package, but not its
+`internal` packages or catalog modules. It must not recreate the removed
+Scriptorium framework facade or former framework package families.
+Adapter-owned interfaces use Promptkit public values when a consumer-side
+substitution boundary is needed. Omitted framework settings pass as zero
+values so Promptkit applies its own defaults. Cross-project changes land and
+release in Promptkit before
+Scriptorium adopts its tagged dependency; do not commit Go workspaces, local
+replacements, vendored Promptkit source, or unpublished dependency assumptions.
+The repository's architecture guard protects these import and removal
+boundaries. Adapter separation does not require an interface for every type,
+extra wrappers, or a fixed directory tree.
 
-## Retained Boundaries
+## Definition Support And Request State
 
-- `internal/adapter/cli` owns commands, flags, configuration precedence,
-  process streams, output files, summaries, and exit codes.
-- `internal/adapter/http` owns routes, strict JSON DTOs, size limits, response
-  mapping, status mapping, and the restricted artifact reader.
-- `internal/config` owns discovery and Scriptorium's application definition;
-  ConfigKit owns strict YAML decoding and the load/override pipeline.
-- `internal/defaults` owns Scriptorium application and HTTP defaults only.
-- `internal/format` owns deterministic prepared-run and definition-inspection
-  text and JSON presentation.
-- Promptkit owns framework orchestration and contracts. Its
-  [format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
-  and
-  [outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
-  are canonical.
+As decided in [ADR 0004](../adr/0004-definition-boundary.md), Scriptorium aims
+to support the complete set of features in valid Promptkit prompt and profile
+definitions for its selected upstream version. Promptkit remains the canonical
+parser and validator. Library-only features are considered individually
+against Scriptorium's simple predefined-prompt execution model.
 
-## HTTP Artifact Security Boundary
-
-Ordinary CLI file loading is provided by Promptkit. Scriptorium's HTTP adapter
-injects a restricted `promptkit.ArtifactReader` for inbound HTTP requests.
-That reader denies file references without an artifact root, enforces the
-configured byte limit, and applies Scriptorium's lexical root-containment rule.
-The operating system still follows symlinks after the lexical check.
-
-This boundary handles untrusted request references under the documented
-deployment model; it is not a filesystem sandbox. Defending against a
-privileged actor concurrently modifying the host filesystem is outside the
-adopted scope, not a claim that such activity cannot occur. Do not infer
-additional defenses or guarantees from hypothetical threats; raise unsettled
-scope decisions under the [agent policy](agents.md).
-
-The [HTTP API](../api.md) owns observable request outcomes, and
-[operations](../operations.md) owns deployment permissions and root selection.
-
-## State, Errors, And Secrets
-
-Scriptorium has no durable run-state store, checkpoint, cache, or resume
-mechanism. Recovery is a new request after correcting inputs, configuration, or
-environment.
-
-Each request is self-contained from the caller's perspective, without
-conversation or workflow state retained from completed requests. This does
-not mean the process is internally stateless. Shared engines, backend capacity
-and queue accounting, in-flight coordination, cancellation, and server
-lifecycle resources are permitted and must be shared where necessary to
-enforce configured backend limits across concurrent requests. Such state must
-be concurrency-safe and does not create a durable user-workflow contract.
-
-Adapters map Promptkit public error identities into CLI exits or HTTP statuses
-without classifying by message text. Raw API keys are not accepted in
-Scriptorium configuration, CLI arguments, or HTTP payloads, and resolved
+External YAML and JSON decoding remains strict. Adapters map external values
+through Promptkit public requests and results without taking over framework
+orchestration. Explicit numeric request overrides preserve presence, including
+zero. Adapters map Promptkit public error identities to CLI exits or HTTP
+statuses without classifying by message text. Raw API keys are not accepted
+in Scriptorium configuration, CLI arguments, or HTTP payloads, and resolved
 secrets must not be emitted.
 
-## Architectural Invariants
-
-- External YAML and JSON decoding remains strict.
-- CLI and HTTP behavior remains presentation and transport logic rather than
-  framework orchestration.
-- Explicit numeric request overrides preserve presence, including zero.
-- HTTP artifact containment and byte limits remain Scriptorium policy.
-- No application package depends on Promptkit implementation packages.
+Each execution request is self-contained from the caller's perspective; no
+conversation or workflow state is retained from completed requests. This
+does not preclude process-scoped operational state. A server shares its
+Promptkit engine, backend registry, capacity admission and queue accounting
+across relevant concurrent requests so configured backend limits cannot be
+bypassed by per-request construction. In-flight coordination, cancellation,
+and server lifecycle state must be concurrency-safe. None of this creates a
+durable workflow, checkpoint, cache, or resume contract; recovery is a new
+request after correcting inputs, configuration, or environment.
 
 ## Non-Goals
 
@@ -153,5 +116,19 @@ secrets must not be emitted.
 - Do not add durable workflow, archive, or resume behavior.
 - Do not add application-managed prompt modification, follow-up message flows,
   conversation management, or multi-step workflow orchestration.
+## Trust Boundaries And Threat Scope
 
-Work that is not implemented belongs in `docs/roadmap/`.
+Ordinary CLI file loading belongs to Promptkit. For untrusted inbound HTTP
+artifact references, Scriptorium injects a restricted
+`promptkit.ArtifactReader`. It denies file references without an artifact
+root, applies the configured byte limit, and enforces lexical root containment.
+The operating system follows symlinks after that lexical check. This is not a
+filesystem sandbox or a defense against a privileged actor concurrently
+modifying the host filesystem; that threat is outside the adopted scope.
+Do not infer stronger defenses from hypothetical threats. Raise unsettled
+scope decisions under the [agent policy](agents.md).
+
+The [HTTP API](../api.md) owns observable request outcomes, the
+[configuration contract](../config.md) owns credential supply, and
+[operations](../operations.md) owns deployment permissions and root selection.
+The [source internals](../internal/sources.md) describe reader mechanics.

docs/policy/documentation.md

@@ -1,15 +1,16 @@
 # Documentation Policy
 
-**Base Policy Version:** 1.4
+**Base Policy Version:** 1.11
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md
 
 ## Purpose
 
 This policy assigns each documentation topic to one canonical owner. Its goal is
-to keep this repository's documentation accurate, concise, discoverable, and
-resistant to drift for users, operators, developers, integrators, and LLM
-coding agents.
+to keep this application's documentation accurate, concise, discoverable, and resistant
+to drift for users, operators, developers, integrators, and LLM coding agents.
 
 ## Core Rules
 
@@ -17,45 +18,38 @@ coding agents.
 
 Each authoritative fact belongs in one document. A non-owning document may give
 a short, stable summary for orientation, but it must link to the canonical owner
-instead of repeating volatile details.
+for volatile details.
 
 Volatile details include commands, flags, configuration fields and defaults,
 module keys, schemas, file names, paths, status codes, retry behavior, and
 runtime guarantees. If readers could reasonably treat a statement as a
 contract, maintain it only in the owning document.
 
-Minimal tested usage examples are allowed outside the owning contract when this
-policy assigns them an orientation or instructional purpose. They must link to
-the canonical contract and must not redefine complete syntax, defaults, or
-semantics.
-
 ### Current And Future Behavior
 
 Outside `docs/roadmap/`, documentation describes implemented behavior only.
 Partial features may be described only to their implemented boundary.
 
-Architectural constraints may govern future changes without implying that the
-components or capabilities they would govern already exist. This does not
-permit describing a proposed system structure as implemented.
+Architectural constraints may govern future changes. Describe current structure
+from implemented behavior.
 
-ADRs may record an accepted architectural decision before implementation, but
-acceptance must not be presented as proof that the behavior exists. The 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.
+ADRs may record an accepted architectural decision before implementation. The
+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. User and operator docs should not expose implementation detail.
-Developer docs should link to user-facing and external contracts rather than
-restate them.
+its owned topic. Keep user and operator docs focused on using and operating the
+application. Developer docs should link to user-facing and external contracts
+for their definitions.
 
 ### Examples
 
 Complete copyable files belong in `examples/`. Documentation may use the
 smallest illustrative snippet needed to explain its owned topic, but should link
-to maintained examples instead of embedding a second complete copy.
+to maintained examples for complete copyable files.
 
 Examples must be valid, secret-free, and tested where practical. Commands and
 configuration used in documentation should match the application.
@@ -71,43 +65,42 @@ secret values.
 
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward, including license and attribution navigation. | Complete command reference, configuration reference, operational procedures, implementation detail. |
-| Contributor entry point | `docs/development.md` | Task-oriented reading guide, minimal contributor orientation, baseline validation commands, and links to canonical docs. | Package inventory, architecture rules, subsystem behavior, and detailed change recipes, which belong in the relevant internal component document. |
-| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, architectural 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 rules, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
-| Documentation organization | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
-| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression-test policy, and criteria for adding, rewriting, or deleting tests. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
+| 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 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. |
+| 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. |
+| 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. |
+| 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. |
+| Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
+| 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 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. |
 | CLI contract | `docs/cli.md` | Commands, arguments, flags, invocation semantics, and exit codes. | End-to-end operating procedures, configuration field definitions, runtime filesystem layout, module implementation details. |
-| Configuration contract | `docs/config.md` | Application discovery and precedence, source locations, server fields, render default, HTTP limits, and credential mapping. | Promptkit framework formats and defaults, complete example files, CLI syntax, runtime lifecycle, and implementation detail. |
-| Operations | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache, and debug handling, resume, cleanup, permissions, recovery, and operational limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
-| Release policy | `docs/policy/release.md` | Versioning and compatibility, release integrity and immutability, documentation requirements, proportionate gates, publication controls, source completion, and optional verification boundaries. | Repository-specific commands, installation guidance, historical summaries, and CI implementation details. |
-| Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, publication command and guards, asynchronous delivery, optional diagnostics, and failure recovery. | General release requirements, runtime operations, historical announcements, and current application contracts. |
-| Version-specific release notes | `docs/releases/` | Immutable release summaries, compatibility notices, and migration announcements for one published version. | Complete CLI, HTTP, configuration, operations, or dependency contracts. |
-| Open source licensing and attribution policy | `docs/policy/oss.md` | House attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
-| Project license | `LICENSE` | The project's own license terms. | Upstream component attribution and dependency license texts. |
-| Upstream component attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General attribution policy and complete standard license texts. |
-| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by attribution entries where applicable. | Project-specific upstream notices, attribution prose, and policy interpretation. |
+| Configuration contract | `docs/config.md` | Application configuration discovery, precedence, schema, fields, defaults, environment overrides, validation, and selectable module and validator keys. | PromptKit framework formats and defaults, complete example files, CLI syntax, runtime state lifecycle, module implementation details. |
+| Operations | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache and debug handling, resume, cleanup, permissions, recovery, and limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
 | Public HTTP contract | `docs/api.md` | Routes, authentication, media types, request and response schemas, status codes, pagination, caching, idempotency, rate limits, and HTTP retry semantics. | Client walkthroughs, upstream or downstream integration internals, implementation detail. |
-| Consumer guidance | `docs/consumers/` | Choosing between Scriptorium's executable interfaces and understanding consumer responsibilities. | HTTP wire semantics, CLI syntax, Promptkit's Go package, and internal implementation detail. |
-| External and durable integration contracts | `docs/integrations/` | Scriptorium-owned process and executable integration contracts. | Promptkit framework formats and outbound provider protocols, physical runtime placement, internal transformations, CLI syntax, and configuration defaults. |
-| Implemented component inventory | `docs/internal/overview.md` | Current packages and components, their implemented responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
-| Internal component behavior | Other files under `docs/internal/` | Implementation flow, internal collaborators and state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
-| Architectural decision history | `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. |
-| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other files intended to be copied or run. | Field-by-field reference, command reference, prose explanation. |
+| Consumer guidance for executable use and migration | `docs/consumers/` | Task-oriented executable use, migration to PromptKit, minimal examples, and consumer responsibilities. | HTTP wire semantics, CLI syntax, PromptKit's public Go API, external protocol contracts, internal implementation detail. |
+| Scriptorium-owned integration contracts | `docs/integrations/` | Scriptorium-owned executable and process contracts, logical output paths and schemas, media types, and compatibility. | PromptKit framework formats and outbound provider protocols, 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. |
 
-Documents that do not exist are required only when the corresponding interface
-or responsibility exists. Do not create placeholder API, consumer, integration,
-or operations documents for behavior the application does not have.
+Create supporting documents for existing interfaces and responsibilities when
+substantive content is available.
 
 ## Boundary Rules
 
 ### Orientation
 
-The README owns product orientation. The developer guide routes contributors.
-Architecture owns normative structure. Internal overview owns the current
-concrete component map. These documents may link to one another but should not
-maintain parallel package or behavior descriptions.
+Link among orientation, architecture, and internal documents; maintain each
+package or behavior description in its canonical owner.
 
 ### Commands, Configuration, And Operations
 
@@ -119,26 +112,25 @@ other contracts.
 
 ### Releases
 
-The release policy owns release requirements; the release procedure supplies
-the commands that satisfy them. Release notes are historical summaries, not
-current-state contract owners. The checked-in note at an immutable tag records
-that release; current documentation changes with the behavior it describes.
-Neither a procedure nor a note may weaken policy or defer required updates to
-canonical contracts.
+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.
 
-### Open Source Attribution
+### Project Licensing And Upstream Attribution
 
-The [OSS policy](oss.md) defines the House Format and README and release-link
-conventions. Attribution entries own component-specific information. README
-and release documents provide navigation to those canonical materials; the
-release procedure owns URL construction and publication mechanics.
+README and release documents link to the canonical licensing and attribution
+materials under the [OSS policy](oss.md). The release procedure owns URL
+construction and publication mechanics.
 
 ### Contracts And Implementation
 
 Integration and API documents define externally observable shapes and
-semantics. Internal documents explain how this project 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.
+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
 
@@ -160,31 +152,13 @@ Use sequentially numbered ADR filenames such as
 6. alternatives considered;
 7. consequences.
 
-Use one of these statuses:
-
-- **Proposed:** the decision is under consideration and may change;
-- **Accepted:** the decision is approved, whether or not implementation is
-  complete;
-- **Rejected:** the proposed decision was considered and not adopted;
-- **Superseded:** a later ADR replaces the accepted decision.
-
-A proposed ADR transitions to accepted or rejected. An accepted ADR transitions
-to superseded only when a later accepted ADR replaces it. An ADR may be created
-as accepted when the decision has already been made.
-
-Treat the decision content of an accepted ADR as immutable. Its status and
-supersession metadata may be updated, but a changed decision requires a new ADR.
-A superseded ADR must link to its replacement, and the replacement must link
-back to the superseded ADR. Rejected architectural alternatives belong in the
-ADR; rejected product ideas belong in the roadmap.
+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.
 
 ## Maintenance
 
-Every policy document records its underlying template version and local
-last-updated date immediately below the title. Update the date when revising
-local policy; change the base version only when adopting a newer template.
-Do not retain template adoption instructions in the local policy.
-
 When behavior changes, update its canonical owner in the same change. If
 ownership moves, remove the old definition and replace it with a link where
 navigation remains useful.

docs/policy/meta.md

@@ -0,0 +1,27 @@
+# Policy Set Provenance
+
+**Base Policy Version:** 1.0
+
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** 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).

docs/policy/oss.md

@@ -1,81 +1,150 @@
 # Open Source Licensing And Attribution Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.8
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md
 
 ## Purpose And Scope
 
-This policy establishes a repeatable House Format for open source attribution
-and license notices. It covers upstream components incorporated into or
-distributed with the project, including relevant transitive dependencies and
-copied code or assets. Treatment follows the component's terms and actual use,
-rather than its classification as a direct dependency.
+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 obligations beyond attribution and notice handling.
+compatibility, or resolve every obligation arising from use or distribution.
 
 ## Canonical Locations
 
 The [documentation policy](documentation.md) assigns ownership:
 
-- `LICENSE` contains the project's own license. Dependency attribution does
-  not relicense the project.
-- `docs/oss/attribution.md` contains the canonical component entries.
-- `docs/oss/licenses/` contains complete, verbatim standard license texts,
-  including companion texts where applicable.
+- `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.
 
-## House Format
+## Upstream Reference Examples
 
-Each component entry has five fields:
+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.
 
-1. **Project name**, normally as the entry heading.
+## 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.
-3. **SPDX license identifier or expression**, when applicable.
-4. **License and notice links**, covering the applicable standard texts and
-   upstream project-specific material.
-5. **Source repository link**, identifying the source corresponding to the
-   imported version.
+   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 `[Source](COMMIT_URL).`.
 
-Illustrative Markdown, with placeholders for the actual upstream information:
+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.
 
-```markdown
-## Example Library
+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.
 
-Copyright <upstream copyright statement>
-
-SPDX-License-Identifier: Apache-2.0
-
-License and notices: [Apache 2.0](licenses/Apache-2.0.txt) | [NOTICE](<upstream NOTICE URL at the imported commit>)
-
-Source: [Example Library](<upstream repository URL at the imported commit>)
-```
-
-These are five fields, not a line limit. Include multiple statements and links
-where needed. Omit the SPDX field when no applicable identifier exists; identify
-nonstandard terms accurately through the linked text. Preserve licensing
-alternatives and exceptions, and record a selected option when relevant. 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 the upstream copies instead of storing them locally. Every upstream
-repository or notice link must identify the exact commit corresponding to the
+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.
-Do not use moving branches or version tags as substitutes for that commit.
 
-Classify material by its contents, not its filename. An upstream `LICENSE`,
+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 rather than leaving readers to infer their location.
+reachable from the entry.
 
 For project-specific license and attribution material, this policy accepts
 direct links to the applicable upstream texts as satisfying reproduction,
@@ -91,17 +160,18 @@ 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
-license and the attribution document. For Scriptorium:
+grant in `COPYRIGHT` and the attribution document. For example, for a project
+with the stated license:
 
 ```markdown
-Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
+Scriptorium is licensed under the [GPL 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 `LICENSE | ATTRIBUTION`. Use absolute URLs to
-those files at the release's immutable tag or corresponding immutable source
+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.
 
@@ -113,8 +183,9 @@ assets, source bundles, or a different binary package format.
 
 ## Maintenance And Exceptions
 
-Update notices in the change that adds, removes, upgrades, copies, or changes
-the distribution of a relevant component. Check the selected source's license
+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.
 
@@ -128,8 +199,10 @@ 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 policy or affected attribution entry as appropriate. Resolve the issue
-before the affected use or distribution without reopening settled choices.
+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,

docs/policy/release.md

@@ -1,8 +1,10 @@
 # Release Policy
 
-**Base Policy Version:** 1.2
+**Base Policy Version:** 1.4
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md
 
 ## Purpose
 
@@ -18,14 +20,13 @@ policy and link to it rather than introduce additional release requirements.
 
 A source release identifies one exact committed source revision through an
 immutable version tag and a version-matched, checked-in release note. The
-primary release branch is `main`; the authoritative publication remote is
-`origin`.
+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. Publish `main` before
-invoking the publication command; the command requires
-that the remote branch exactly identifies the validated candidate and pushes
-only the selected annotated tag.
+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
@@ -34,19 +35,20 @@ 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.
 
-Scriptorium publishes Linux binaries and checksums asynchronously from the
-tagged source. The procedure must identify those deliverables and the
+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.
 
-Artifact delivery is a separate status. A successful tag push is not evidence
-that artifacts are available. Delivery failures do not reverse source-release
-success, and optional investigation must not delay release completion.
+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 are not part of the adopted release channel.
+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.
@@ -76,9 +78,13 @@ 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. Keep the note proportionate to the change. Fixed sections and
-explicit no-action boilerplate are not required. Existing historical notes
-need not be rewritten to adopt this format.
+instructions. Choose sections suited to the release 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
@@ -86,18 +92,11 @@ 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.
 
-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. A release note must not substitute for current documentation.
-Use annotated tags with their message derived from the checked-in note rather
-than requiring a separately authored account of the same release.
-
-Version selection, release-note content, and retirement of completed roadmaps
-are preparation responsibilities, not separate human approval gates. Preserve
-planned and deferred work and repair affected links when retiring roadmaps.
-Ordinary change review covers unintended files, credentials, and private data;
-do not repeat it as a release-specific sign-off. Ignored local files are not
-prohibited merely because they exist: they are not included in the tagged source.
+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
 
@@ -107,24 +106,10 @@ 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), and 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.
-
-The selected test invocation includes the race detector because the HTTP
-service shares engines and backend capacity state across concurrent requests.
-This single invocation covers both ordinary assertions and race detection.
-Build both declared Linux architectures with the hosted release flags to catch
-cross-compilation and packaging failures; native test hardware for each target
-is not required. Existing architecture tests enforce dependency boundaries.
-
-Retain narrow source guards against committed workspaces, vendor trees, and
-module replacements: these can otherwise make a passing local build depend on
-unpublished or substituted framework code. Disable workspace discovery and
-vendor mode during validation. These guards preserve the established
-cross-project boundary; they do not require exact dependency-version audits or
-module-metadata rewrites at release time.
+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
@@ -134,8 +119,8 @@ 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 describes
-dependency preparation separately from offline validation.
+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;
@@ -158,7 +143,9 @@ Automate the checks needed to publish the intended source under a fresh version:
 - 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 exact candidate; and
+- 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.
 
@@ -211,3 +198,27 @@ 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.
+
+## Scriptorium Release Selections
+
+Scriptorium publishes stable releases from `main` through the authoritative
+`origin` push endpoint. The validated candidate is published to the remote
+branch before the annotated version tag; the publication command requires
+exact agreement between the remote branch and candidate before pushing only
+that tag. Atomic branch-and-tag publication and source-only delivery remain
+general alternatives in this policy, not Scriptorium-supported workflows.
+The tag message derives from the checked-in note. A successful tag push
+completes the source release; binary delivery is asynchronous and does not
+gate it.
+
+The tagged source produces Linux amd64 and arm64 binaries and checksums through
+the hosted workflow. Candidate validation runs the complete offline Go suite
+once with the race detector because concurrent HTTP requests share engine and
+backend capacity state. It builds both declared Linux targets. Narrow guards
+reject committed workspaces, vendor trees, and module replacements so local
+substitutions cannot mask unpublished framework code. These selected checks
+address distinct application and release risks; no CI polling, artifact
+availability, consumer installation, or new approval gate is required.
+
+The [release procedure](../release.md) owns exact commands, targets, guards,
+delivery reporting, and recovery steps.

docs/policy/testing.md

@@ -1,14 +1,16 @@
 # Testing Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
+
+**Upstream Source:** 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
 
@@ -22,9 +24,9 @@ Evaluate that tradeoff 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?
 
-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.
+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.
 
-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.
+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.
 
 ## Default testing style
 
@@ -56,7 +58,7 @@ To the extent the following features are present in the application, prioritize
 6. Previously observed or plausible regressions.
 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.
 
 Choose tests for requested behavior and established contracts. Tests must not
 introduce new restrictions, guarantees, or threat scenarios merely because they
@@ -75,14 +77,8 @@ Do not add tests merely because a function, branch, or line exists. Do not add a
 
 ## Choose the right test boundary
 
-Test through the narrowest stable boundary that expresses the behavior clearly.
-
-For application configuration, ConfigKit owns exhaustive YAML grammar,
-source traversal, import/overlay composition, provenance, and inspection
-renderer tests. Scriptorium tests its selected definition, source discovery,
-CLI override presence, command prerequisites, runtime conversion, credential
-boundary, and representative execution/inspection workflows with the tagged
-library. Do not copy the upstream parser test matrix into this repository.
+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:
 
@@ -90,22 +86,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 end-to-end 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. A test must not memorialize the current implementation.
+A test should protect a selected decision, contract, or invariant.
 
-A test is suspect when its main purpose is to detect that someone:
+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.
 
-- 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.
+Behavioral tests should normally remain stable through internal refactoring that preserves the contract.
 
 ## Expected effects of different changes
 
@@ -122,7 +111,7 @@ 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.
 
 For this example, assume the selected contract rejects a request to start more
 processes than a configured limit. Do not encode its production default indirectly:
@@ -158,33 +147,52 @@ 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 established concurrency limits, distinguish these behaviors where the contract requires them:
 
 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:
 
-- Configuration tests own application YAML, strict decoding, discovery,
-  precedence, and application defaults.
-- CLI tests own argument mapping, streams, summaries, exit behavior, and
-  representative command workflows.
-- HTTP tests own DTOs, strict decoding, limits, status mapping, and restricted
-  artifact policy.
-- Formatter tests own prepared-run and definition-inspection text and JSON
-  presentation.
-- Architecture tests own dependency direction and removal invariants.
+- Parser tests own parsing cases.
+- Validator tests own validation rules.
+- Domain tests own transformations and invariants.
+- Adapter tests own external integration behavior.
+- Orchestrator tests own coordination and failure propagation.
+- CLI tests own argument and configuration mapping.
+- End-to-end tests prove that representative assembled workflows work.
+
+Give each layer its distinct responsibility and keep expectation updates localized to the contract being changed.
+
+## Scriptorium Test Ownership
+
+- Application configuration tests own Scriptorium's definition, strict
+  decoding at its boundary, source discovery and selection, explicit CLI
+  override presence, application defaults, runtime conversion, and safe
+  diagnostics. ConfigKit owns exhaustive YAML grammar, source traversal,
+  import and overlay composition, provenance, and inspection renderers.
+- CLI tests own argument mapping, streams, output, exit behavior, and
+  representative run, render, inspect, serve, and config workflows.
+- HTTP tests own DTO decoding, transport limits, status and error mapping,
+  restricted artifact reading, and representative server workflows.
+- Formatting tests own prepared-run and definition-inspection text and JSON
+  presentation. Architecture guards own dependency direction and removed
+  framework-package boundaries.
 - Promptkit owns framework parsing, orchestration, validation, profiles, and
-  model-client behavior. Scriptorium's definition compatibility fixtures protect
-  its adapter plumbing without duplicating the upstream format contract.
+  model-client behavior. Scriptorium's definition and execution fixtures
+  protect adoption through its public adapter boundary without duplicating
+  Promptkit's exhaustive format matrix.
 
-Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
+HTTP lexical containment, size limits, and shared engine and backend capacity
+across concurrent requests merit focused adapter coverage because violations
+cross a security or concurrency boundary. Choose cases by realistic risk
+rather than a coverage quota or a duplicated upstream matrix.
 
 ## Use test doubles deliberately
 
@@ -205,12 +213,9 @@ 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
 
-Select techniques according to the behavior and risk being tested. The following
-are options, not a checklist that every package or application must satisfy:
+Select techniques by behavior and risk:
 
 - table-driven tests for meaningful behavioral categories and boundaries;
 - `t.TempDir()` for real filesystem behavior;
@@ -220,55 +225,48 @@ are options, not a checklist that every package or application must satisfy:
 - integration tests where correctness depends on component interaction; and
 - 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 CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Do not snapshot complete diagnostic wording unless it is contractual.
+At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Use complete diagnostic snapshots only when the wording is contractual.
 
 Golden-file updates must require an explicit local flag. CI must not update golden files automatically, and reviewers 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.
-
-Security-sensitive HTTP containment and external mappings may warrant denser
-coverage than straightforward process wiring. Uneven coverage is acceptable
-when it reflects risk.
+Pure domain logic will often warrant higher coverage than CLI wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
 
 ## 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 a test when its maintenance cost exceeds the confidence it provides.
+Delete or rewrite tests when maintenance cost exceeds their continuing
+protective value.
 
 Strong candidates include tests that:
 
 - require updates after harmless internal changes;
-- directly assert private constants without protecting a real contract;
-- duplicate the same policy across several layers;
+- assert incidental private constants or snapshot large amounts of incidental output;
 - verify mock choreography rather than outcomes;
-- snapshot large amounts of incidental output;
-- test trivial private helpers already exercised through stable package behavior;
-- protect risks already covered more effectively elsewhere;
+- duplicate policy across layers, retest trivial helpers covered by package
+  behavior, or protect risks 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.
 
 ## 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. Which requested behavior or established contract does it protect, and what realistic defect would violate it?
 2. How likely and consequential is that defect, and is it already protected elsewhere?
@@ -282,10 +280,9 @@ A test suite is sufficient when:
 
 - important requested behavior and established contracts are protected against realistic, consequential failures;
 - boundaries and component interactions have coverage where they introduce meaningful risks not protected elsewhere;
-- failures provide useful signal rather than redundant noise;
-- legitimate internal changes usually do not require test edits; and
+- failures provide useful, distinct signals;
+- tests usually remain stable through legitimate internal changes; and
 - additional tests would mostly repeat existing protection or preserve inconsequential implementation details.
 
-Sufficiency is a risk judgment, not a coverage percentage, test count, or required
-mix of testing techniques. Reassess it as the application, its users, and the
-consequences of failure evolve.
+Reassess sufficiency as the application, its users, and the consequences of
+failure evolve.

docs/release.md

@@ -23,20 +23,19 @@ Choose an unused stable version under the release policy. Commit its note as
 `docs/releases/<version>.md`, beginning with a title such as
 `# Scriptorium v0.14.0` (an example, not an instruction to select that version).
 Include a concise summary and relevant compatibility impact or upgrade action.
-End the note with the following footer, replacing `<version>` in both absolute
+End the note with the following footer, replacing `<version>` in all three absolute
 URLs with the selected version tag (for example, `v0.14.0`):
 
 ```markdown
-[LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/docs/oss/attribution.md)
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/docs/oss/attribution.md)
 ```
 
-Check that both URLs name files in the candidate tree at that tag. The tag may
+Check that all three URLs name files in the candidate tree at that tag. The tag may
 not resolve online until publication. The checked-in note is copied unchanged
 into the hosted release body by the existing workflow, so do not maintain a
 second footer there.
 Update affected canonical documentation with the change, and retire completed
 roadmap material when appropriate while preserving deferred work and links.
-No extra release-specific review signoff is required.
 
 Finish and commit the intended candidate on `main`, then publish that branch:
 
@@ -63,9 +62,8 @@ remote version, exact agreement with authoritative remote `main`, and a
 checked-in note whose first-level title contains Scriptorium and the exact
 version. Ignored local files do not make the candidate dirty.
 
-The existing source-boundary guards reject committed workspaces, vendor trees,
-and module replacements. No migration-specific exact Promptkit version audit
-is required.
+The source-boundary guards reject committed workspaces, vendor trees, and
+module replacements.
 
 It then runs the complete suite once with the race detector and builds Linux
 amd64 and arm64 binaries using `CGO_ENABLED=0`, `-trimpath`, and

docs/releases/v0.15.0.md

@@ -0,0 +1,26 @@
+# Scriptorium v0.15.0
+
+This minor release changes Scriptorium's application grant to GPL version 3 or
+later, aligns its repository policies and attribution notices, and updates the
+selected Promptkit and ConfigKit patch releases.
+
+## Licensing and upgrade impact
+
+Scriptorium's application source and binaries are now distributed under
+GPL-3.0-or-later. Review [COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/COPYRIGHT)
+and [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/LICENSE)
+before redistributing or incorporating this version. Material adapted from
+Standard Repository Policies remains separately licensed under CC-BY-SA-4.0;
+the [attribution notices](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/oss/attribution.md)
+identify its scope and license text. Existing dependency grants are unchanged,
+and earlier tagged releases retain their own published terms.
+
+## Dependency updates
+
+Scriptorium now selects Promptkit v0.11.2 and ConfigKit v0.4.2. The current
+[CLI](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/cli.md),
+[HTTP API](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/api.md),
+and [configuration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/config.md)
+references describe the executable contracts.
+
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/oss/attribution.md)

docs/roadmap/configkit.md

@@ -3,9 +3,10 @@
 ## Status And Intent
 
 Implemented feature direction, drafted on 2026-09-26 and delivered through the
-[implementation plan](implementation.md). This roadmap records the target
-behavior and changes from the reviewed baseline; the implementation plan owns
-sequencing, concrete interfaces, and verification evidence.
+historical plan at
+`git show 8452b54809b99425a97940da485daaa48c77aeb8:docs/roadmap/implementation.md`.
+This roadmap records the target behavior and changes from the reviewed baseline;
+that Git record owns sequencing, concrete interfaces, and verification evidence.
 
 The user is adopting ConfigKit across an application suite to standardize
 configuration semantics. Scriptorium will make a clean cutover to ConfigKit's

docs/roadmap/implementation.md

@@ -1,536 +1,303 @@
-# ConfigKit Adoption Implementation Plan
+# Policy Alignment Implementation Plan
 
-## Status, Authority, And Historical Plans
+## Status, Scope, And Authority
 
-Planned on 2026-09-26 against Scriptorium commit
-`43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c`. This document records the
-ordered implementation and its completion evidence. The maintainer resolved
-the inspection-policy question:
-`extra_params` remain visible; only API-key values require secret protection.
+Planned on 2026-09-28 against Scriptorium
+`8452b54809b99425a97940da485daaa48c77aeb8`. All five stages are complete.
+The ordered stages below retain the implementation instructions and completion
+evidence for this delivered work set.
 
-The [feature roadmap](configkit.md) owns scope, target behavior, and user intent.
-This plan owns implementation steps and the interface choices needed to execute
-them. Read [development](../development.md) and every policy before work:
-[agents](../policy/agents.md), [architecture](../policy/architecture.md),
-[documentation](../policy/documentation.md), [testing](../policy/testing.md),
-[release](../policy/release.md), and [OSS](../policy/oss.md).
-[ADR 0004](../adr/0004-definition-boundary.md) continues to govern Promptkit's
-definition boundary. Do not rewrite accepted ADR decisions.
+The [feature roadmap](policy.md) owns the agreed end state, scope, and reasons
+for local exceptions. This plan owns execution steps and acceptance checks.
+This is documentation work, not application, dependency, or release-tool work.
 
-This filename previously contained completed Promptkit plans. Older roadmap
-links to this file refer to these historical records, not the ConfigKit stages:
+The selected public upstream revision is
+`d84a38ebab26f048cafbe59a2246700c35d29843`.
+Start with its
+[adoption guide](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md).
+Retrieve source files at this revision, not whatever main contains when a
+stage runs. A verified checkout of this exact revision is acceptable; no
+sibling checkout is a prerequisite. If source retrieval fails, report that
+blocker rather than inventing source content or provenance.
 
-- Completed v0.11 implementation and release handoff:
-  `git show 43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c:docs/roadmap/implementation.md`.
-- Completed v0.9 implementation:
-  `git show e4405966c87c8a7843b340146e90cc1e515bef42:docs/roadmap/implementation.md`.
+Read the current local agent policy and developer orientation before work,
+then policies governing the stage. Once Stage 2 lands, use the new selective
+reading guide. Reuse unchanged policy text already available in context.
 
-Those deliveries must not be repeated or lost from upcoming release preparation.
-These Git records are available locally without publishing the recent commits.
+## Historical Implementation Records
 
-## Working Rules And Selected Design
+This filename previously held completed application plans. Preserve their
+records through Git rather than carrying their implementation steps forward:
 
-The dependency target is `gitea.maximumdirect.net/eric/ConfigKit v0.4.0`,
-commit `e6ced0d3d1194b58e0b3dc8970089471ba175258`. Use its public root package,
-imported as `configkit`. The roadmap links the exact upstream contracts.
-Do not opportunistically upgrade Promptkit or other dependencies, commit a
-workspace/replacement, or depend on sibling source at runtime.
+- ConfigKit adoption and release handoff:
+  `git show 8452b54809b99425a97940da485daaa48c77aeb8:docs/roadmap/implementation.md`.
+- Earlier PromptKit plans are referenced within that historical document.
 
-This is a clean configuration cutover, not a compatibility project. Native
-ConfigKit syntax, presence, nullability, resource limits, and precedence apply.
-Do not add a pre-parser, YAML serialization round trip, alternate merge engine,
-legacy mode, generic provider abstraction, or a new CLI framework.
+Those stages must not be rerun. Existing release notes, including
+[the v0.14.0 note](../releases/v0.14.0.md), record prior delivered features.
+Do not infer a new release obligation from an old prospective handoff.
+The new policy and licensing changes still need a concise summary in the next
+release, including the already-selected GPL-3.0-or-later application grant and
+the separately licensed policy material. Version selection and publication
+are not part of this plan.
 
-Keep application source discovery and domain rules in `internal/config`;
-CLI parsing/output stays in `internal/adapter/cli`. Promptkit remains responsible
-for prompt/profile/schema parsing, backend semantics, credentials, and engine
-behavior. Keep one shared server engine and existing HTTP artifact policy.
-No HTTP schema, execution-report, request-timeout, or retry-orchestration change
-is part of this plan.
+## Common Execution Rules
 
-For every stage:
+1. Inspect status and relevant diffs before each stage. Preserve unrelated
+   changes; do not silently include them in the stage commit.
+2. Read the selected upstream files completely before adopting them. Compare
+   directly with local files; do not reconstruct historical adoption baselines.
+3. Start from upstream text, remove the complete Base Policy Template section,
+   and apply only the customizations selected below. Preserve shared language
+   verbatim, including its meaning and strength. Do not retain old paraphrases
+   merely because they are familiar or add prohibitions for hypothetical risks.
+4. For each policy adopted in that stage, set the target Base Policy Version,
+   the actual adoption date, and an Upstream Source link:
+   `https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/FILE.md`.
+   Substitute the actual filename. Do not stamp a source on a policy before
+   incorporating it. Intermediate commits may legitimately have mixed versions.
+5. Update the single policy-attribution entry as its copied/adapted scope grows.
+   Do not claim later-stage material has already been adopted.
+6. Validate affected text, links, notices, and diff; record concise completion
+   evidence under the completed stage here. Commit each coherent stage with a
+   short plain-English message under the agent policy. Do not push or publish.
 
-1. Inspect the working tree and relevant code/tests through the repository's
-   code-discovery guidance. Preserve unrelated changes.
-2. Implement the listed outcome and only supporting refactoring it needs.
-   Internal names below are selected implementation guidance, not public APIs
-   or immutable package-layout contracts.
-3. Update canonical current-state docs when behavior lands. Until Stage 3 the
-   new loader is internal preparation, not an advertised executable feature.
-   Never claim later stages are implemented.
-4. Run focused tests and the development guide's baseline validation for code
-   changes. Tests stay offline, deterministic, and free of real credentials.
-   Reuse existing coverage rather than cloning ConfigKit's parser test matrix.
-5. Format changed Go files, inspect the diff, validate affected docs/examples,
-   record stage status/evidence here, and commit the coherent unit. Do not push,
-   tag, publish, or add new release gates.
+Do not change Go code, module pins, tests, release scripts, CI, accepted ADR
+decisions, or published release notes. Do not introduce recurring sync checks,
+license approval rounds, release gates, or blanket source headers. Preserve
+the application grant and dependency terms. Standard license text must remain
+verbatim even if a generic whitespace check dislikes publisher formatting.
 
-### Application Configuration Definition
+## Stage 1: Adopt OSS Rules And Establish Licensing Notices
 
-Use a new `Document` type in `internal/config` for the native configuration
-shape. It replaces the old on-disk `Config` after CLI cutover. Keep the familiar
-YAML field names:
+**Status: Complete.** OSS language was compared with the pinned source after
+the approved metadata and example changes. The CC-BY-SA text matches its pinned
+source byte-for-byte; attribution and navigation were checked against the
+specified format and local paths.
 
-| YAML path | Go shape | Default and selected meaning |
-| --- | --- | --- |
-| `prompt_dir`, `profile_dir` | `string` | Empty; no source configured. |
-| `schema_dir` | `string` | Existing schema-directory default. Empty remains empty at the application boundary; Promptkit owns any subsequent framework default. |
-| `transient_retries` | `*int` | Nil; omitted/null delegates, zero disables additional attempts. |
-| `server` | Non-pointer struct | Its children receive typed defaults; null is invalid. |
-| `server.addr` | `string` | Existing listen-address default when absent; explicit empty is passed unchanged to the standard HTTP server, not replaced with the Scriptorium default. |
-| `server.artifact_root` | `string` | Empty; HTTP file input remains disabled. |
-| Three `server.max_*_bytes` fields | `int64` | Existing defaults; explicit zero disables the respective limit; null is invalid. |
-| `defaults` | Non-pointer struct | Contains `render_format`; null is invalid. |
-| `defaults.render_format` | `string` | Existing text default; resolved value must be text or json. Explicit empty is invalid, not defaulted. |
-| `backends` | `map[string]BackendDocument` | Nil; null is permitted, an empty mapping follows ConfigKit semantics. |
+Files: `docs/policy/oss.md`, `docs/oss/attribution.md`,
+`docs/oss/licenses/CC-BY-SA-4.0.txt`, `COPYRIGHT`, `README.md`,
+and the footer portion of `docs/release.md`.
 
-`BackendDocument` keeps `endpoint string`, `api_key_env string`,
-`extra_params map[string]any`, `concurrency_limit int`, and
-`queue_capacity *int`. Scalar nulls are invalid; nullable maps/pointers retain
-native semantics. No catalog IDs or Promptkit fields are added.
+1. Read upstream OSS v1.8, COPYRIGHT, the canonical
+   `examples/licensing/policy-attribution.md`, and referenced licensing
+   examples at their pinned URLs. Adopt OSS v1.8 with metadata as above.
+   Remove template-only content; retain upstream common wording and its
+   existing commit-pinned example links. Customize the README example to
+   Scriptorium and GPL v3 or later. No other OSS exception is selected.
+2. Copy the complete CC-BY-SA-4.0 reference text from the selected revision
+   into the named local license file and compare it byte-for-byte with that
+   source. Do not copy the rest of the reference collection or add CC0 merely
+   because example formatting is used.
+3. Reformat the attribution document to the exact v1.8 House Format. Use
+   `# Open Source Attribution Notices`, immediately followed by entries.
+   Place Standard Repository Policies first, using the canonical entry,
+   with its COPYRIGHT, LICENSE, and Source URLs pinned to the selected full
+   commit. In this stage identify `docs/policy/oss.md` as the newly adapted
+   material. Do not research or make claims about prior adoption provenance.
+4. Preserve the eight existing dependency entries and their imported commits,
+   copyright wording, SPDX expressions, and required notices. Optional module
+   identification paragraphs may retain versions currently in source labels.
+   Remove the introductory prose, missing-copyright filler, and editorial
+   YAML license explanations. Preserve the factual MIT AND Apache-2.0
+   expressions. Use actual upstream filename labels, local license names,
+   terminal periods, and the exact `[Source](COMMIT_URL).` source form.
+   Do not upgrade dependencies or relabel their grants.
+5. Add a scoped paragraph to COPYRIGHT stating that material adapted from
+   Standard Repository Policies remains CC-BY-SA-4.0, with
+   `docs/oss/attribution.md` identifying affected material and links. This
+   covers the scoped material as stages add it; it does not relicense unrelated
+   application code or documentation. Keep the existing GPL grant and LICENSE.
+6. Correct the README ending to link GPL v3 or later to COPYRIGHT and keep
+   the attribution link. Change the release-procedure footer to absolute
+   immutable-tag COPYRIGHT, LICENSE, and ATTRIBUTION links, updating the
+   references to the number of URLs. Change no publication commands.
+   Do not retrofit published notes or create a release note/version now.
 
-The fresh defaults factory reads existing `internal/defaults` and format
-constants, not a duplicated set of literals. Normalization trims surrounding
-whitespace from application directory strings, artifact root, and server
-address; cleans only nonempty application paths; and lowercases/trims
-`defaults.render_format`. Empty paths remain empty: never let
-`filepath.Clean("")` turn disabled/unset into `.`. Record actual changes with
-`configkit.Normalize`, using value-free reasons. Do not normalize backend
-fields or parameter values on Promptkit's behalf.
+Acceptance: OSS text matches the pinned source except the approved project
+example and metadata; attribution follows the prescribed format; the added
+license text is faithful; project and dependency grants remain unchanged.
+Check affected local paths and upstream notice/example destinations. Missing
+copyright fields are omitted, not explained with agent-authored commentary.
 
-The read-only validator reports negative application size limits, negative
-nonnull application retries, and invalid render format through
-`Validation.Error` at their field paths. It does not print rejected values.
-Do not call the existing format parser's empty-as-default branch for this field.
-Do not add endpoint, backend ID, credential-presence, directory-existence,
-address-format, or positive-only-capacity checks. Existing Promptkit and
-command-specific validation retains those responsibilities where applicable.
+## Stage 2: Adopt Provenance, Agent Guidance, And Documentation Ownership
 
-## Stage 1: Add The Dependency And Native Application Definition
+**Status: Complete.** The three policies carry the selected versions, source
+links, and local adoption date; shared text and the orientation template were
+compared with the pinned source. The seven-link reading guide and local links
+were checked, and attribution names only the incorporated material.
 
-**Status: Complete.** The pinned dependency, native definition, focused
-presence/normalization/validation tests, and commit-specific attribution are in
-place. The existing executable loader remains active pending the command cutover.
+Files: new `docs/policy/meta.md`, `docs/policy/agents.md`,
+`docs/policy/documentation.md`, root `AGENTS.md`,
+`docs/development.md`, and the policy attribution entry.
 
-Primary files: `go.mod`, `go.sum`, new focused files under `internal/config`,
-and `docs/oss/attribution.md`.
+1. Adopt meta v1.0 and agents v1.3 verbatim after template-section removal
+   and metadata substitution. Keep meta's live project and main-branch
+   adoption-guide discovery URLs; its own Upstream Source is commit-pinned.
+   Retain local relative links to developer guidance and attribution.
+2. Adopt documentation v1.11. Customize only applicable topic-map rows:
+   configuration remains application configuration, framework formats belong
+   to PromptKit, consumers cover executable use and migration rather than a
+   Scriptorium public Go API, and integrations cover Scriptorium-owned
+   executable/process contracts. Keep upstream rows for meta, COPYRIGHT,
+   LICENSE, and attribution. Remove instructional “if applicable” qualifiers
+   from selected rows. Preserve the rest of the shared language.
+3. Use the upstream ADR lifecycle and examples guidance without retaining
+   generic local expansions. This does not edit accepted ADRs or change their
+   decisions. Metadata maintenance follows the adoption guide through meta,
+   rather than a duplicate custom rule set.
+4. Adapt upstream `agents/AGENTS.md` into root AGENTS.md. Preserve any actual
+   repository-specific code-discovery instructions; do not copy environment-
+   injected instructions into the file just because they appeared in a session.
+   Do not copy upstream's own root AGENTS.md.
+5. Add the adoption guide's Policy Reading Guide table and selection bullets
+   verbatim to the developer guide with the seven local links. Replace its
+   unconditional architecture-reading instruction and duplicated policy-reading
+   prose with this selective guide. Retain project orientation, task-specific
+   contract rows, dependency boundaries, and baseline validation commands.
+   Avoid maintaining competing policy trigger rules in multiple places.
+6. Expand the policy entry's Material sentence to identify the adopted OSS,
+   meta, agents, and documentation policies plus adapted root AGENTS.md and
+   the copied Policy Reading Guide section of docs/development.md. Mark them
+   adapted for this repository; do not imply the whole developer guide or
+   unrelated tooling instructions have changed license.
 
-1. Add ConfigKit at the selected release. Retain Promptkit v0.11.0 and its
-   selected catalogs. Provision dependencies outside offline test execution.
-   ConfigKit's yaml/v4 release-candidate dependency is the reviewed upstream
-   choice, not an instruction to upgrade its parser independently.
-2. Implement `Document`, `BackendDocument`, the fresh defaults factory,
-   recorded resolver, and read-only validator described above. Keep the old
-   loader operational until Stage 3 so this stage remains independently
-   buildable; this temporary development state is not a shipped compatibility
-   mode or a second user-selectable configuration path.
-3. Test the new definition using real `configkit.Load[Document]` with
-   `Bytes` and `NoSource`. Cover explicit zero/empty/null distinctions,
-   retry/queue nil-versus-zero, safe application validation, and a normalized
-   path whose effective output agrees with the returned value. Include nested
-   unknown fields and a representative dynamic numeric parameter.
-4. Add ConfigKit and yaml/v4 attribution from their selected source material.
-   Resolve the imported yaml/v4 commit from release/module metadata. Preserve
-   actual copyright statements; do not infer a project statement from the
-   FSF license-document copyright. Use applicable SPDX expressions, local
-   standard texts, and commit-pinned upstream license/notice links. Reuse GPL,
-   LGPL, MIT, and Apache texts where applicable, including companion links.
-   Retain yaml.v3 attribution because Promptkit still incorporates it.
-5. Document the internal definition as preparation in the relevant internal
-   guide without claiming the CLI has switched. No current configuration
-   contract changes yet.
+Acceptance: all stage policies have their own correct source link and version;
+orientation selects policies by task, including meta for adoption work; local
+links resolve; no upstream handbook or example collection was copied.
+Generic language differences from upstream are eliminated, not rephrased.
 
-Acceptance: the dependency and definition compile, focused tests demonstrate
-native semantics and audited normalization, and attribution follows the OSS
-policy. Existing executable behavior still passes its tests.
+## Stage 3: Adopt Architecture And Testing With Narrow Local Decisions
 
-## Stage 2: Build Discovery And The Shared Loading Boundary
+**Status: Complete.** The three shared architecture sections and the common
+testing text match the pinned source. Local architecture decisions were checked
+against the accepted ADRs and internal guides; focused test ownership and the
+expanded attribution scope were reviewed without changing application code.
 
-**Status: Complete.** Ordered source discovery, one ConfigKit load, typed
-diagnostics, and settings conversion are covered by focused file/default and
-override tests. Existing commands still use the old entry point until cutover.
+Files: `docs/policy/architecture.md`, `docs/policy/testing.md`,
+policy attribution entry, and focused internal docs only if moving existing
+implementation detail requires it.
 
-Primary files: `internal/config` and its tests; `docs/internal/sources.md`.
+1. Read the existing architecture, relevant accepted ADRs, source/adapter
+   internal guides, and the pinned architecture v1.3 template. Retain upstream
+   Purpose And Ownership, Architectural Approach, and Adopted Constraints And
+   Implemented Structure text verbatim. Replace the Application-Specific
+   Topics placeholder with Scriptorium's existing substantive decisions.
+2. Preserve public PromptKit/ConfigKit responsibility boundaries, definition
+   support, strict decoding, presence handling, HTTP artifact containment,
+   request independence and concurrency-safe shared capacity, credential/error
+   boundaries, dependency restrictions, and explicit workflow non-goals.
+   Retain the existing lexical containment and privileged-host threat scope,
+   not a stronger filesystem-sandbox promise. Customize the trust discussion
+   to those decisions rather than retaining instructional example prose.
+3. Correct system shape to include run, render, serve, inspect, and config.
+   Link to internal documentation for concrete package inventory/mechanics.
+   Where material moves, preserve it in its canonical internal owner without
+   duplicating it. Do not introduce new wrappers, ports, orchestration, or
+   package constraints merely to “implement” the architectural recommendation.
+4. Adopt testing v1.3 common text verbatim. Add one clearly identified local
+   test-ownership section for configuration, CLI, HTTP, formatting, architecture
+   guards, and PromptKit/ConfigKit boundaries. Preserve the existing distinction
+   between adoption/integration fixtures and upstream exhaustive tests.
+   Retain a short application-specific note explaining HTTP containment and
+   shared-state risks where useful; do not replace upstream risk-based coverage
+   guidance or create percentage targets, quotas, or new test requirements.
+5. Add accurate source/version/date metadata and extend the policy attribution
+   scope to architecture and testing. Record any moved adapted prose in the
+   Material scope if it is placed outside the already identified files.
 
-1. Add `LoadOptions` with `Path string`, `Explicit bool`, `Overlay string`,
-   and `Overrides []configkit.Override`, plus
-   `Load(LoadOptions) (*configkit.Result[Document], error)`.
-   Discovery chooses a source; the one ConfigKit call owns actual file reading
-   and decoding. Return the result so consumers retain the frozen inspection
-   snapshot as well as the typed configuration.
-2. With `Explicit=true`, pass the selected path to `configkit.File`;
-   an explicitly empty path is invalid, not implicit discovery or a fallback
-   to the old system filename. Do not silently trim a source filename into a
-   different filename. ConfigKit validates and resolves file sources.
-3. With `Explicit=false`, ignore the option's path value and examine the
-   existing ordered implicit search locations. Only nonexistence permits
-   examining the next candidate. Other stat failures are errors. Select the
-   first existing candidate and let ConfigKit load it. A selected file's later
-   disappearance/read/parse failure does not restart discovery.
-4. If neither implicit candidate exists, use `NoSource`. Initially leave
-   imports disabled and the overlay empty; Stage 4 enables composition.
-   Defaults-only loads still accept explicit application overrides. Never
-   reinterpret an empty file as `NoSource`.
-5. Pass overrides into the ConfigKit call before decoding/validation; do not
-   validate a separately merged lower configuration first. Native parsing and
-   composition failures still follow the upstream lifecycle and are not
-   bypassed by CLI overrides.
-6. Add a small `Settings(Document) AppSettings` conversion for existing
-   executable wiring. It copies resolved fields, maps the already-validated
-   format, and converts the backend map into ID-sorted backend settings.
-   It performs no file IO, normalization, credential lookup, semantic backend
-   checks, or additional defaults. Dynamic values retain their decoded shapes.
-7. Preserve ConfigKit's typed `*LoadError` through wrapping so the CLI can
-   render safe structured diagnostics. Discovery-only errors are concise and
-   quote paths safely; no new public error taxonomy is needed.
-8. Test ordered discovery with temporary paths rather than host system files,
-   explicit missing/empty paths, empty-file rejection versus `{}`,
-   defaults-only loading, source records, override-before-validation behavior,
-   sorted backend conversion, and preservation of zero/nullable values.
-   Remove no existing entry point until all its CLI callers migrate in Stage 3.
+Acceptance: direct comparison isolates only the roadmap's justified local
+decisions; shared text matches upstream. Architecture describes existing
+behavior accurately without implementation work. Testing preserves ownership
+without duplicating upstream matrices or imposing new coverage gates.
 
-Acceptance: real files and defaults-only inputs produce one reusable result,
-runtime conversion agrees with it, and tests do not depend on machine-wide
-configuration or secrets. The old and new internals are temporarily buildable,
-with no new user-visible mode.
+## Stage 4: Adopt Release Policy Without Changing Publication Behavior
 
-## Stage 3: Cut Existing Commands Over And Remove The Legacy Loader
+**Status: Complete.** The shared release language matches the pinned source;
+the local selections match the existing script, hosted workflow, and runbook.
+Commands, build targets, recovery behavior, and the three-link footer remain
+unchanged. Attribution now names all seven adopted policies.
 
-**Status: Complete.** All five command modes use the shared ConfigKit loader;
-the legacy decoder and merge path are removed. CLI and configuration contracts
-now describe native YAML and override behavior. Full test, race, vet, build,
-and diff checks passed.
+Files: `docs/policy/release.md`, `docs/release.md`, attribution entry.
 
-Primary files: `internal/adapter/cli/run.go`, `inspect.go`,
-`internal/config/config.go`, and associated tests.
+1. Read the current release policy, procedure, script, and hosted workflow;
+   inspect them read-only. Adopt upstream release v1.4 common wording.
+2. Add a compact Scriptorium-specific section preserving the established
+   selections: main/origin, branch-before-tag publication with exact remote
+   candidate agreement, annotated tags derived from the checked-in note,
+   stable releases only, asynchronous Linux binaries/checksums, one race-enabled
+   offline test invocation, and source-boundary guards. Keep rationale for
+   selected gates in policy and command/target details in the procedure.
+3. Retain upstream's general alternatives verbatim but state which existing
+   approach Scriptorium selects. Atomic push and source-only release remain
+   template-supported alternatives, not newly supported Scriptorium workflows.
+   Preserve successful tag publication as completion; no CI polling, artifact
+   availability, or consumer installation gate is added.
+4. Align the procedure with this allocation without changing its commands,
+   required checks, supported platforms, or failure-recovery behavior. Confirm
+   the Stage 1 three-link footer survives hosted-body reuse. Do not run the
+   publication command or mutate remote state to validate documentation.
+5. Add metadata and expand the policy attribution scope to all seven policies.
+   The final Material description also identifies adapted AGENTS.md and the
+   developer-guide reading section, plus any actually moved adapted text.
 
-1. Route run, render, serve, inspect prompt, and inspect profile through the
-   shared `Load` and `Settings` boundary. Preserve the explicit presence of
-   `--config` in every parser. Centralize the small application-flag mapping
-   rather than reproduce it in each command.
-2. Use `flag.FlagSet.Visit` (or the existing explicit-set helper) to create
-   one `configkit.Override` per explicitly supplied application flag. Use
-   `configkit.Keys`, built-in scalar values, and a safe `Flag` label containing
-   only the flag name. Standard flag parsing's last occurrence supplies the
-   single override; do not emit duplicate records or parser defaults.
+Acceptance: the existing release workflow still satisfies the resulting policy
+with no script/CI changes. Source completion, delivery status, immutability,
+tag type, and validation obligations are unchanged. All seven source links
+identify their own file at the selected full commit.
 
-   | Flag | Application path | Existing command scope after cutover |
-   | --- | --- | --- |
-   | `--prompt-dir` | `prompt_dir` | run, render, serve, inspect prompt |
-   | `--profile-dir` | `profile_dir` | run, render, serve, inspect profile |
-   | `--schema-dir` | `schema_dir` | run, render, serve |
-   | `--addr` | `server.addr` | serve |
-   | `--artifact-root` | `server.artifact_root` | serve |
-   | `--max-request-bytes` | `server.max_request_bytes` | serve |
-   | `--max-artifact-bytes` | `server.max_artifact_bytes` | serve |
-   | `--max-response-bytes` | `server.max_response_bytes` | serve |
+## Stage 5: Verify Language Parity And Complete The Documentation Handoff
 
-   Register the schema-directory flag on render as well as run/serve so the
-   advertised application path override is consistently usable. This is not a
-   general expansion of runtime/provider flags to other commands.
-3. Keep `--format`, `--out`, request `--transient-retries`, prompt/profile
-   selection, model overrides, timeouts, inputs, variables, and reporting
-   options outside the application configuration tree. In particular,
-   `render --format` overrides that invocation's output format without
-   rewriting `defaults.render_format`; omitted format inherits its resolved
-   application value. Existing invocation-only parsing remains unchanged.
-4. Remove post-load directory trimming/cleaning/defaulting from argument
-   finalizers, including unconditional schema-path cleaning. Keep only
-   invocation-owned transformations such as output-file paths. Explicit
-   empty profile/artifact-root overrides must clear file-provided values;
-   explicit empty prompt directory must reach the existing execution
-   prerequisite rather than revive the lower value.
-5. Keep existing command prerequisites: run/render/serve and prompt inspection
-   need their effective prompt directory as currently required; profile
-   inspection does not acquire a prompt-directory requirement. All commands
-   still perform the common application schema validation. Do not introduce
-   eager filesystem or credential validation for inspection.
-6. Add one CLI diagnostic path using `errors.As` and
-   `configkit.WriteDiagnostics` for load errors. Carry successful load warnings
-   to the command boundary and render them once on stderr before execution or
-   output. Handle diagnostic writer errors as command failures. Do not flatten
-   structured failures into raw parser text or print rejected values.
-   Preserve existing process exit classifications; application/parse/load
-   failures are exit 1, not generated-output validation exit 2.
-7. Remove the old YAML decoder, `strictInteger.UnmarshalYAML`, old on-disk
-   types, `applyConfig`, `ApplyCLIOverrides`, and unused compatibility
-   sentinels/helpers after migrating all callers/tests. Keep only one defaults
-   factory. Remove the direct yaml.v3 import; module tidy may retain yaml.v3
-   as an indirect Promptkit dependency.
-8. Update tests to the deliberate breaking semantics, not the legacy behavior.
-   Protect explicit empty path clearing, scalar-null rejection, unknown fields,
-   rejected empty/multi-document input, one representative YAML policy change,
-   unchanged request-versus-engine retry precedence, absent optional
-   credentials, and command-specific inspection prerequisites.
-9. Update configuration and CLI contracts, source/adapter internals, architecture
-   ownership, and the contributor reading guide for the delivered cutover.
-   Preserve existing application defaults, Promptkit definition support,
-   HTTP containment, shared capacity, and report behavior. Adjust the current
-   CLI claim that every command requires a prompt directory to match actual
-   command-specific requirements.
+**Status: Complete.** All seven policies were compared directly with the pinned
+upstream files; differences are limited to metadata, removed template text,
+the selected project example and topic rows, and the identified local sections.
+The copied license matches byte-for-byte. A Markdown-aware check resolved 86
+local links; historical plan references resolve to Git objects. Attribution,
+notice scope, release navigation, and the final documentation-only diff were
+reviewed without changing application or publication artifacts.
 
-Acceptance: all existing commands use ConfigKit, no legacy parser or second
-application merge remains, relevant tests pass, and diagnostics and docs describe
-the native breaking behavior. Imports/overlays and new inspection commands are
-not yet advertised.
+Files: this plan, the feature roadmap, and only affected documentation needing
+correction within the preceding stages' scope.
 
-## Stage 4: Enable Explicit Imports And Selected Configuration Overlays
+1. Compare all seven adopted documents directly with their selected upstream
+   counterparts. Account for metadata, removed template sections, approved
+   substitutions, and the narrow local sections. Correct every remaining
+   non-substantive wording difference. Do not turn this comparison into a
+   permanent script, CI requirement, or release gate.
+2. Check there are no adoption placeholders, copied template-only instructions,
+   absent local example links, stale BSD descriptions of Scriptorium itself,
+   or contradictory selective-reading directions. Legitimate BSD dependency
+   attribution remains. Validate links using Markdown-aware handling so
+   illustrative syntax in inline code is not treated as a broken real link.
+3. Confirm per-document source metadata, the policy entry's exact scope,
+   COPYRIGHT's scoped license treatment, existing dependency grants/notices,
+   and the byte-for-byte new license text. Keep example/source links pinned
+   and public discovery links current. Check footer paths in the candidate;
+   unpublished release tags need not resolve online.
+4. Review affected roadmap references to implementation.md. Where a link
+   specifically means an old completed plan, replace it with a clear historical
+   Git reference from this plan, not this new policy sequence. Preserve
+   deferred application features and historical completion evidence.
+   Current release directions link to the canonical procedure, not an old
+   two-link footer. Do not rewrite published release notes.
+5. Mark only actually delivered stages complete with concise evidence here.
+   Update the feature roadmap's status to delivered and keep its end-state
+   focus. Record the next-release summary described above without choosing a
+   version, creating a tag, or claiming publication.
+6. Run diff/whitespace and affected-document/link checks. Do not reformat
+   verbatim license text to satisfy a style check. No Go test/build rerun is
+   necessary for this documentation-only work; no executable example or
+   publication command needs changing. Inspect status and staged diff, commit,
+   and report the commit and remaining work under the agent policy.
 
-**Status: Complete.** File-backed loads support explicit imports and one
-selected overlay under the selected file's canonical directory. All five
-existing command modes accept `--config-overlay`; real-file composition and a
-render workflow are tested. The composed example and contracts are updated;
-full test, race, vet, build, and diff checks passed.
-
-Primary files: shared loader, CLI source-selection wiring, configuration and
-CLI tests, maintained configuration examples.
-
-1. Enable `Options.Imports` for file-backed loads. Leave it false for
-   `NoSource`, which rejects imports. Use ConfigKit's default canonical
-   selected-file directory as the root; do not supply a wider filesystem root
-   or add application traversal code.
-2. Wire `LoadOptions.Overlay` into `Options.Overlay`. Register
-   `--config-overlay` on all five existing configuration-loading command
-   modes. Treat the value exactly as an upstream overlay name: no trimming,
-   case folding, extension fallback, path expansion, or local inheritance.
-   Empty and exact lowercase default mean no active overlay under v0.4.0.
-   A requested active overlay without a selected base source fails through
-   ConfigKit; do not manufacture an empty base file or root.
-3. Use native `configkit.imports` directives for explicit paths/globs. The
-   application enables the feature without requiring a second CLI opt-in;
-   absent directives cause no discovery. Retain conflict-based base
-   composition and native overlay replacement/null semantics.
-4. Preserve working-directory-relative application path values even when
-   authored in fragments or overlays. Configuration-source containment is
-   not the HTTP artifact policy and is not applied to prompt/schema paths.
-5. Add focused real-file tests for disjoint backend fragments, an import
-   conflict, overlay replacement, explicit CLI precedence, missing selected
-   overlay, and no-base overlay failure. Verify `--profile` still selects a
-   Promptkit execution profile independently of `--config-overlay`.
-   One real command workflow proves wiring; upstream owns exhaustive glob,
-   symlink, cycle, and parser-limit tests.
-6. Add a small synthetic import/overlay example under `examples/`; preserve
-   a simple single-file quickstart. Update config/CLI contracts and operations
-   guidance for the new features, root selection, and relative-value policy.
-
-Acceptance: supported commands load the same native composition pipeline;
-imports are explicit, overlays remain distinct from execution profiles, and no
-new scanning, remote acquisition, or path policy is introduced.
-
-## Stage 5: Add Application Validation, Effective Output, And Source Inspection
-
-**Status: Complete.** Application-only validation, effective YAML, and ordered
-JSON source inspection use one shared ConfigKit result without an engine. Tests
-cover source composition, CLI provenance, stream failures, and the credential
-reference boundary. Public and internal contracts are updated; full test,
-race, vet, build, and diff checks passed.
-
-Primary files: a focused `internal/adapter/cli/config.go`, shared config
-definition, CLI dispatch/help/tests, and canonical CLI/config documentation.
-
-1. Apply the maintainer's selected inspection policy: no redaction for
-   `extra_params`, including historical values. API-key values are the only
-   relevant secrets, but this schema stores only `api_key_env` reference names.
-   Keep those names visible and never resolve them in the ConfigKit load.
-   Do not add secret tags to the reference name or parameter container, a
-   catch-all secret predicate, sensitive-key guessing, or a selective masking
-   interface. Actual credentials remain with Promptkit; raw API-key fields
-   remain rejected. Use upstream inspection renderers without adding a second
-   value-rendering path or a synthetic credential field.
-2. Add a top-level `config` command family using the existing standard-library
-   flag style. The selected interfaces are:
-
-   | Command | Success stdout |
-   | --- | --- |
-   | `scriptorium config validate [flags]` | Empty; exit status communicates application validation success. |
-   | `scriptorium config show [flags]` | `Result.WriteEffective` redacted YAML. |
-   | `scriptorium config sources [flags]` | One newline-terminated JSON array of source records. |
-   | `scriptorium config explain --path <pointer> [flags]` | Added in Stage 6. |
-
-   These are prospective interface specifications, not commands to execute
-   before their stages are implemented.
-3. All configuration subcommands accept `--config`, `--config-overlay`,
-   and the eight application override flags in Stage 3's table, regardless
-   of which execution command normally uses them. They do not accept request,
-   credential, backend-editing, output-format, or output-file flags. Shell
-   redirection is sufficient for these inspection outputs. No positional
-   arguments are accepted.
-4. Load exactly once through the common loader. Do not construct a Promptkit
-   engine, restricted artifact reader, listener, or client. Missing prompt
-   directories, unselected/absent credentials, and framework backend validity
-   are not additional application-inspection gates. Invalid application
-   types/ranges/format still fail. Validation describes application load
-   validity, not end-to-end executability.
-5. For sources, map `Result.Sources()` to a small local DTO with JSON keys
-   `id`, `label`, `layer` (always present), and `path` (omit when empty).
-   Preserve upstream source order; emit `[]\n` for defaults-only input without
-   overrides. Include synthetic CLI sources where present. Do not marshal
-   opaque ConfigKit implementation objects. The standard JSON encoder escapes
-   control characters; no custom terminal rendering is necessary.
-6. Diagnostics/warnings go only to stderr through the shared diagnostic helper.
-   Successful operations exit 0; parse/load/output/diagnostic-write failures
-   exit 1. No exit 2 meaning is introduced for configuration validation.
-   Ordinary writer failures may leave partial output; do not promise atomic
-   streams or buffering of an entire configuration.
-7. Test defaults-only show/sources, a composed load with CLI provenance,
-   explicit empty clearing, normalized effective values, failed loads producing
-   no successful stdout, and writer failure. Set a synthetic API-key environment
-   variable: effective output must show its reference name, not its value.
-   Repeat with the variable absent to establish that inspection does not require
-   credentials. Assert that ordinary synthetic parameter values remain visible
-   and runtime ExtraParams stay intact; no real environment or provider is used.
-8. Update CLI/config contracts, README navigation, subprocess integration,
-   operations, and internal inventory to describe only these delivered modes.
-   Retain the README's license/attribution ending.
-
-Acceptance: validation, effective output, and source inspection use the same
-resolved configuration as execution, preserve stream separation, and honor the
-selected API-key boundary without masking or changing backend parameter data.
-
-## Stage 6: Add Per-Path Explanation And Verify Credential Boundaries
-
-**Status: Complete.** `config explain` uses required JSON Pointer paths and
-ConfigKit's snapshot renderer, including historical and normalized values.
-Tests cover root, escaped/numeric keys, unknown paths, writer failures, and
-synthetic credential-reference boundaries. Full test, race, vet, build, and
-diff checks passed.
-
-Primary files: configuration command implementation/tests and CLI/config docs.
-
-1. Implement `config explain` with the same selectors and override flags as
-   Stage 5 plus a required, explicitly supplied `--path`. Parse using
-   `configkit.ParsePath`; syntax is JSON Pointer, not dotted notation, a file
-   path, or a URL fragment. Explicit `--path ""` selects the root; an omitted
-   flag is an error. Preserve escaped and numeric mapping-key semantics.
-2. Use the successful shared result's `WriteExplanation`. Explain known
-   effective and historical paths, including removed values. An unknown or
-   malformed path exits 1 with no successful explanation output. Quote
-   user-supplied paths safely if included in application diagnostics.
-   Do not rebuild history, look up environment values, or reload sources.
-3. Keep the upstream human-readable renderer and its redaction semantics rather
-   than inventing a JSON explanation schema or freezing the entire rendered
-   prose as an application guarantee. Writer failures exit 1 and can leave
-   partial output, as with effective output.
-4. Test a value's default/base/overlay/CLI history, recorded normalization,
-   explicit equal-value writes, an escaped backend key, root selection, and
-   an unknown path. Cover a displaced historical backend parameter value:
-   it remains visible, including in a container/root explanation. Use distinct
-   synthetic environment names and key values to verify reference names remain
-   explainable but resolved API-key bytes are absent from all history/output.
-5. Update CLI/config docs and operations guidance with path syntax,
-   historical-value meaning, representation differences, and sensitive
-   identifiers/paths. Do not claim that redaction detects arbitrary secrets
-   outside classified paths.
-
-Acceptance: explain uses the existing snapshot and upstream semantics; its
-history matches the selected inputs and normalization, parameters remain
-visible, and explanation neither resolves nor discloses API-key values.
-
-## Stage 7: Verify Integration, Finish Documentation, And Record Release Handoff
-
-**Status: Complete.** The feature roadmap, command paths, dependency boundary,
-documentation, and attribution were audited. Maintained single-file and
-composed examples passed configuration inspection and no-provider rendering;
-the optional-credential/integer-parameter backend path passed with a local
-provider. The full test, race, vet, build, formatting, link, and diff checks
-passed. Release preparation is recorded below; no tag or publication occurred.
-
-1. Review the feature roadmap against actual code. Confirm all five original
-   command modes and all four new configuration subcommands use one definition
-   and load pipeline. Remove any transitional loader, duplicated defaults,
-   unused compatibility helpers, or post-snapshot configuration mutation.
-   Do not add architecture machinery merely to assert a particular file layout.
-2. Exercise maintained single-file and import/overlay examples through the
-   implemented configuration commands and a no-provider render workflow.
-   Use focused backend integration evidence that dynamic integer parameters
-   reach Promptkit correctly and missing optional credentials retain their
-   established meaning. Use a local HTTP server only where provider serialization
-   must be checked; never a real service or credential.
-3. Retain existing HTTP concurrency, containment, error mapping, retry,
-   timeout, and report tests. Add a representative configuration-to-server
-   wiring test only if existing coverage misses changed settings propagation;
-   do not reproduce all upstream scheduling or HTTP cases.
-4. Run the development baseline on final code: `go test ./...`,
-   `go test -race ./...`, `go vet ./...`, and
-   `go build ./cmd/scriptorium`. Check formatting, affected examples/links,
-   and `git diff --check`. Do not stage the built binary or scratch files.
-   Compare any new standard license text byte-for-byte; preserve upstream
-   whitespace rather than editing license wording to satisfy a style check.
-5. Ensure current configuration, CLI, subprocess, operations, internal docs,
-   contributor routing, and architecture ownership agree. Testing policy
-   should identify ConfigKit as the owner of exhaustive upstream loading tests,
-   while Scriptorium owns application adoption tests. Change policy dates when
-   revising policies, not base versions unless adopting new templates.
-   Keep accepted ADR text and published release notes immutable.
-6. Record the release handoff below and mark only delivered stages complete.
-   Update the feature roadmap's status, including the resolved inspection
-   decision. Preserve deferred work. The next breaking release follows the
-   release policy; version selection, candidate publication validation, release
-   notes at that version, tag creation, and publishing are not this sprint.
-7. Commit the final coherent handoff and report validation evidence, remaining
-   limitations, and any outstanding work without claiming source/binary
-   publication or complete legal compliance.
-
-Acceptance: the ConfigKit-native target is delivered with proportionate
-regression evidence and accurate documentation, and the workspace contains no
-temporary dependency substitutions or uncommitted implementation artifacts.
-
-### Release Handoff To Retain
-
-The upcoming release needs migration guidance for empty files versus `{}`,
-explicit empty values, nullable versus scalar fields, strict YAML/scalars,
-reserved keys and upstream size limits, and the invalid explicit-empty config
-path. Include imports/overlays, application path interpretation, CLI presence,
-inspection command scope, and the selected API-key-only secret policy. Explicit
-empty server address reaches standard HTTP server behavior instead of restoring
-Scriptorium's default; operators should supply their intended listen address.
-
-Keep request retry overrides and Promptkit credential semantics distinct from
-application settings. Explain that configuration validation is not a provider
-probe or complete Promptkit definition validator, and that inspection output
-is not guaranteed reloadable. Include dependency/attribution changes and the
-existing LICENSE | ATTRIBUTION footer. Preserve the still-relevant Promptkit
-v0.11 release handoff identified above when preparing a combined next release.
-
-### Implementation And Release Preparation Record
-
-The ConfigKit v0.4.0 adoption is implemented in committed source. The next
-breaking release still needs version selection, version-matched release notes,
-candidate validation, tagging, and publication under the release policy; none
-has occurred as part of this work. Keep the earlier Promptkit v0.11 handoff
-linked above when preparing a combined release.
-
-The release note should summarize the deliberate configuration migration:
-empty files now fail and `{}` means an empty mapping; explicitly empty strings
-and zero values override lower values; `null` follows declared nullable types;
-strict YAML rejects additional documents, anchors/aliases, unsupported scalar
-forms, and unknown fields; `configkit` is reserved and ConfigKit's source and
-resource limits apply. Explicit `--config ''` is invalid. Imports are opt-in
-per file directive, while `--config-overlay` selects one named overlay under
-the selected file's canonical directory; application path *values* remain
-process-working-directory-relative. Only explicitly supplied application CLI
-flags override configuration. An explicit empty server address is passed to
-the standard HTTP server and does not restore Scriptorium's default.
-
-Document the four application-inspection modes and the selected policy:
-`extra_params`, including history, and `api_key_env` reference names remain
-visible, but actual API-key bytes are never resolved by ConfigKit. Inspection
-output can be sensitive and is not guaranteed reloadable. Application
-validation neither probes a provider nor completely validates Promptkit
-definitions. Keep request retry overrides and Promptkit's credential rules
-separate from application settings. Include the new dependency and attribution
-notices, and retain the existing LICENSE | ATTRIBUTION footer. Deferred
-secrets bootstrap, schema versioning, reload, and remote acquisition remain
-deferred; do not imply source or binary publication has happened.
+Acceptance: policy language is standardized with only justified local
+customization; notice/provenance arrangements describe reality; no runtime,
+dependency, publication, or historical-release change slipped into the diff.
 
 ## Open Questions
 
-None remain for this scope. On 2026-09-26 the maintainer selected no redaction
-for `extra_params` and specified that the API key is the only secret requiring
-ConfigKit redaction. Stages 5–6 implement that decision through visible parameter
-values/reference names and the existing separation of actual credentials from
-application configuration. Do not reopen it or substitute blanket masking.
-
-This does not claim automatic detection of credentials embedded in arbitrary
-strings or provider parameters. The application schema still rejects raw API-key
-fields, and Promptkit remains responsible for resolving named credential sources.
+None. The maintainer approved the public discovery URLs, the standard
+CC-BY-SA arrangement for copied policy material, the selected upstream revision,
+and the justified local variations. The existing application grant, dependency
+grants, and release approach remain unchanged; do not reopen them merely to
+perform this adoption.

docs/roadmap/policy.md

@@ -1,63 +1,223 @@
-# OSS Policy Adoption
+# Standard Repository Policy Alignment
 
-## Status
+## Status And Intent
 
-Completed on 2026-09-26. The upstream template work proposed here is now
-available and adopted locally. This document records the adoption; the
-[OSS policy](../policy/oss.md) is the canonical owner of the ongoing rules.
+Agreed and delivered on 2026-09-28. This roadmap replaces the
+earlier licensing-only proposal with alignment of the complete applicable
+policy set and its supporting documentation. It defines the targeted end state
+and required changes; the [implementation plan](implementation.md) owns ordered
+stages and their verification.
 
-The adopted baseline is the standard policy repository at commit
-`eea8bcd21a964b395e31971077d7fddb445f2c28`:
+The next release summary should mention the policy and licensing alignment,
+the already-selected GPL-3.0-or-later application grant, and the separate
+CC-BY-SA-4.0 treatment of adapted policy material. Version selection and
+publication remain release preparation, not part of this delivery.
 
-- OSS policy base version 1.1;
-- documentation policy base version 1.4; and
-- release policy base version 1.2.
+The goal is identical policy language across adopting projects except where a
+substantive, locally significant requirement or decision warrants customization.
+Adopt upstream wording verbatim for non-substantive differences. Existing local
+phrasing is not, by itself, a reason to retain a variation.
 
-Each affected policy records its base version and local update date. Template
-adoption instructions were removed. Unchanged agent, architecture, and testing
-policies retain their existing versions.
+## Review Revision And Current Baseline
 
-## Adoption Outcome
+The fixed upstream review revision is
+`d84a38ebab26f048cafbe59a2246700c35d29843`.
+Use the [adoption and update guide at that revision](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md)
+for this adoption. The review compared current local documents directly with
+that revision; reconstruction or assessment of historical adoption baselines
+is not required.
 
-- [Documentation ownership](../policy/documentation.md) distinguishes the
-  project license, component entries, standard texts, and OSS policy.
-- The [contributor guide](../development.md) routes dependency, copied-asset,
-  attribution, and release-document work to the OSS policy.
-- [Component entries](../oss/attribution.md) cover the six selected direct and
-  transitive Go modules. Source and project-specific notice links identify the
-  imported commits. LGPL entries link directly to both LGPL v3 and GPL v3.
-- Project-specific notices are linked upstream under the adopted house
-  interpretation. YAML's former local LICENSE and NOTICE copies were removed;
-  their history remains in Git. Missing upstream copyright statements are
-  identified in the affected entries rather than fabricated.
-- The five applicable standard texts in `docs/oss/licenses/` match the upstream
-  reference collection byte-for-byte: GPL v3, LGPL v3, Apache 2.0, BSD 3-Clause,
-  and MIT. The reference collection documents their publisher/SPDX provenance.
-  Adoption removed a stray LGPL prefix, restored the complete Apache text,
-  separated the standard BSD text from the Go-specific notice, and added MIT.
-- The [README](../../README.md) ends with friendly project-license and
-  attribution links. The [release policy](../policy/release.md) delegates footer
-  conventions to the OSS policy; the [release procedure](../release.md) retains
-  Scriptorium's immutable-tag URLs and existing hosted-body reuse.
+The reviewed Scriptorium revision is
+`d6aecf5c50269b7d130dbf19f416a67454cd9778`. It has six adopted policies,
+without per-document Upstream Source metadata, and no `docs/policy/meta.md`.
+The policy targets below supersede the earlier roadmap's narrower version
+targets.
 
-## Preserved Scope
+| Policy and proposed Upstream Source | Current base | Target base | Target treatment |
+| --- | --- | --- | --- |
+| [agents.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md) | 1.1 | 1.3 | Adopt shared rules verbatim, including commit discipline. |
+| [architecture.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md) | 1.1 | 1.3 | Adopt common principles and customize for Scriptorium's established boundaries. |
+| [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md) | 1.4 | 1.11 | Adopt shared language and tailor the canonical topic map. |
+| [testing.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md) | 1.1 | 1.3 | Adopt shared guidance with focused local test ownership. |
+| [release.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md) | 1.2 | 1.4 | Adopt common rules and retain justified release choices. |
+| [oss.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md) | 1.1 | 1.8 | Adopt licensing, attribution, and reference-example conventions. |
+| [meta.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md) | Not adopted | 1.0 | Add provenance, local authority, and upstream discovery. |
 
-This adoption changes documentation and attribution, not Scriptorium's license,
-dependencies, application architecture, or release machinery. Published notes,
-tags, and assets remain unchanged. Existing source-release completion and
-asynchronous binary-delivery behavior remain intact.
+Every existing policy needs language and provenance updates. No adopted policy
+is entirely update-free, but established application decisions, dependency
+licenses, and release mechanics need no substantive change.
 
-There is no new publication-time network check, approval gate, scanner, source
-bundle, downloadable license asset, or modified-dependency rebuild exercise.
-Concrete exceptions continue to receive the treatment specified by the adopted
-OSS policy; the house format is not a universal legal-sufficiency guarantee.
+Current supporting-document gaps include the README's obsolete BSD project
+license statement, the release procedure's two-link footer, an attribution
+document that does not follow the new exact House Format, and orientation
+guidance that requires architecture reading even for unrelated work.
+The architecture policy's command inventory also omits the implemented
+`config` command family.
 
-## Validation
+## Target Policy Language And Local Customizations
 
-The standard texts were compared against the upstream reference collection.
-The BSD reference intentionally retains its publisher's trailing space in the
-copyright placeholder; it is not reformatted to satisfy a whitespace check.
-Dependency commit references were resolved from Go module origin metadata or
-the selected upstream tag, and affected local links and upstream attribution
-destinations were checked. No runtime code, commands, or executable examples
-changed.
+Remove every `Base Policy Template` section and its adoption instructions.
+Replace instructional application-specific placeholders with actual decisions;
+do not leave template examples describing nonexistent components.
+
+Use upstream common language verbatim. Keep necessary local requirements
+clearly identifiable rather than paraphrasing entire shared sections.
+The following customizations are justified:
+
+- **Architecture:** preserve PromptKit and ConfigKit ownership, full support
+  for valid PromptKit definitions, public dependency boundaries, HTTP artifact
+  containment, and simple predefined-prompt execution. Preserve caller-visible
+  request independence alongside shared engine and backend capacity state.
+  These are deliberate product and safety decisions, not generic template
+  choices. Adopt upstream architectural principles proportionately; they do
+  not require a wrapper or interface for every library. Correct the command
+  inventory and keep concrete package mechanics in internal documentation.
+- **Documentation ownership:** tailor the topic map to the executable CLI and
+  HTTP application. Scriptorium does not offer a reusable public Go API;
+  consumer guidance covers executable use and migration to PromptKit.
+  PromptKit remains the owner of framework formats. Use upstream wording for
+  generic ownership, example, and ADR guidance instead of retaining redundant
+  local paraphrases. Preserve accepted ADR decisions and their history.
+- **Testing:** retain a short project-specific ownership section distinguishing
+  Scriptorium's integration and adapter tests from upstream framework/parser
+  tests. This prevents duplication of PromptKit and ConfigKit test matrices.
+  HTTP containment and shared-capacity behavior justify focused adapter
+  coverage. Upstream observations about domain coverage are not quotas or a
+  hierarchy that displaces risk-based testing.
+- **Release:** preserve branch-before-tag publication, annotated tags,
+  Linux amd64/arm64 binaries and checksums, and asynchronous artifact delivery.
+  Retain race testing because the server shares concurrent engine state and
+  source guards because local replacements, workspaces, or vendoring can hide
+  unpublished dependency substitutions. Keep gate rationale in policy and
+  concrete commands, targets, and publication choices in the release procedure.
+  Upstream's optional atomic-push approach does not require a new feature.
+- **OSS:** use Scriptorium's actual GPL-3.0-or-later grant in the project
+  example. Preserve dependency grants and the settled House Format
+  interpretation for upstream notice links. The code grant does not extend
+  to separately licensed copied policy material.
+
+No agent-policy exception is needed: upstream already preserves the local
+commit authorization and safety boundaries. Stylistic preferences, alternate
+wording, and generic elaboration do not justify additional exceptions.
+
+## Provenance And Public Discovery
+
+When adoption lands, each of the seven policies records its target
+`Base Policy Version`, actual local adoption date in `Last Updated`, and
+`Upstream Source` pointing to the exact corresponding file linked in the
+table above. Do not substitute a repository homepage, moving branch, another
+policy's URL, or a historical source revision for that per-document link.
+Retain accurate provenance in later local edits.
+
+The new local `docs/policy/meta.md` follows upstream language after removing
+its template section. It establishes that adopted local policies govern the
+repository and that upstream changes require deliberate adoption. Its public
+discovery links remain current:
+
+- [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
+- [Current adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
+
+Adopted-source and example links remain commit-pinned. Preserve the valid
+commit-pinned example links supplied in the selected OSS policy; their asset
+revision need not be rewritten merely to match the policy review revision.
+Public discovery and attribution in this agreed adoption supersede the earlier
+instruction not to reference the policy repository.
+
+## Orientation And Selective Reading
+
+Adapt [the upstream agent orientation](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/agents/AGENTS.md)
+into [root AGENTS.md](../../AGENTS.md), preserving applicable existing
+code-discovery instructions. It points to the local contributor guide and
+requires the agent policy before recommendations, planning, or implementation;
+it does not require reading the entire suite by default.
+
+The [contributor guide](../development.md) gains the upstream Policy Reading
+Guide table and associated selection rules, including the new meta policy.
+Retain Scriptorium's task-specific contract guide alongside it. Architecture
+reading becomes task-triggered rather than unconditional. Relevant policies
+are read before governed decisions, multiple policies may apply, material
+already available in context may be reused, and expanded scope triggers
+expanded reading. Policy-reading triggers live here, not in the documentation
+topic map.
+
+## Licensing And Attribution
+
+Follow the [canonical copied-policy attribution entry](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/examples/licensing/policy-attribution.md).
+Insert it directly beneath the prescribed attribution title and replace all
+three placeholder URLs with the full review commit. Identify the actual
+copied/adapted scope, including agent-orientation material and copied reading
+guidance where used, rather than describing only policy files if additional
+material is incorporated. Preserve creator, copyright, license, disclaimer,
+and modification information through the supplied notices and links.
+
+Required supporting changes:
+
+- Add the complete, unmodified `docs/oss/licenses/CC-BY-SA-4.0.txt` from the
+  selected revision.
+- Extend [COPYRIGHT](../../COPYRIGHT) to identify the adapted policy material
+  as CC-BY-SA-4.0 and point to attribution for exact scope. Preserve
+  Scriptorium's GPL-3.0-or-later code grant and existing [LICENSE](../../LICENSE).
+  Unrelated application documentation is not automatically relicensed.
+- Reformat [attribution](../oss/attribution.md) to the v1.8 House Format:
+  `# Open Source Attribution Notices`, followed directly by component entries;
+  factual optional identification; supplied copyrights; SPDX expressions;
+  license/notice links with actual filename labels and terminal periods;
+  and `[Source](COMMIT_URL).`.
+- Remove its introductory policy prose, missing-copyright filler, and
+  agent-authored license-scope explanations. Omit an unavailable copyright
+  field instead of explaining that none was invented. Preserve actual
+  required upstream notices, applicable license expressions, and imported
+  dependency revisions.
+- Correct [README](../../README.md) to link its GPL v3 or later statement to
+  `COPYRIGHT`, followed by the attribution link.
+- Update [the release procedure](../release.md) to use the prospective
+  `COPYRIGHT | LICENSE | ATTRIBUTION` footer, with absolute immutable-release
+  URLs for all three destinations. The existing hosted workflow continues
+  copying the checked-in release note unchanged.
+
+The documented CC-BY-SA arrangement is agreed for this adoption. Original
+licensing-example formatting has upstream's CC0 permission; using it alone
+does not require a separate attribution entry. Reproduced license texts and
+third-party notices retain their own terms.
+
+## Local Materials And Upstream References
+
+Keep applicable adopted policies, Scriptorium's adapted root orientation and
+developer guide, actual project notices, attribution entries, and required
+license texts locally.
+
+Keep the upstream adoption guide, README, root AGENTS.md, developer guide, and
+example collection upstream. Link to them as appropriate rather than copying
+them into a parallel local handbook. The upstream `agents/AGENTS.md` is the
+downstream orientation template, distinct from upstream's own root AGENTS.md.
+Copy only needed standard license texts, not the entire reference collection.
+
+## Scope And Completion Criteria
+
+This work updates policy and supporting documentation. It does not change
+application code, dependency versions or grants, release scripts, publication
+mechanics, or accepted ADR decisions. No new scanner, recurring synchronization
+check, license approval, publication-time network probe, or release gate is
+introduced. Published releases, tags, notes, and assets remain unchanged.
+
+Completion means:
+
+- All seven policy files use the selected versions, accurate source links,
+  adoption dates, and upstream common wording, with template-only content
+  removed and local variations limited to the justified decisions above.
+- Orientation and selective reading agree, and local links resolve without
+  depending on a sibling checkout.
+- Policy attribution and document-license scope match the material actually
+  incorporated; required standard texts are complete and unmodified.
+- README, attribution, release navigation, and still-operative roadmap
+  handoffs agree with the new conventions. Historical implementation evidence
+  remains available through the Git references in the implementation plan,
+  without making old footer directions current policy. The earlier
+  author-selected license change remains in the next release's preparation
+  context; publication remains separate work.
+- Review checks the resulting rules, source/example URLs, notice facts, local
+  links, license-text fidelity, and final diff. Runtime tests are unnecessary
+  for documentation-only changes. A Git adoption record is sufficient; no
+  additional provenance database or recurring audit is required.
+
+There are no unresolved policy choices for this scope.

docs/roadmap/promptkit-v0.9.0-adoption.md

@@ -3,8 +3,9 @@
 ## Status
 
 Complete. This document records the delivered feature scope and targeted end
-state. The completed delivery plan is maintained in
-[implementation.md](implementation.md); current behavior remains defined by
+state. The completed delivery plan is preserved at
+`git show e4405966c87c8a7843b340146e90cc1e515bef42:docs/roadmap/implementation.md`;
+current behavior remains defined by
 the canonical application contracts linked below.
 
 The durable product and integration boundary for this work is established by

docs/roadmap/upgrade-kit.md

@@ -8,7 +8,8 @@ and publication remain separate release preparation. The baseline descriptions
 below record the state when this roadmap was written, not current behavior.
 Upgrade directly from Promptkit v0.9.0 to v0.11.0, including the intervening
 v0.10.0 catalog transition. This document defines the desired end state and
-the changes from the current baseline. The [implementation plan](implementation.md)
+the changes from the current baseline. The historical plan at
+`git show 43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c:docs/roadmap/implementation.md`
 owns sequencing, concrete interface choices, verification steps, and unresolved
 implementation decisions.
 
@@ -268,6 +269,6 @@ boundaries.
   the version-matched note remain release preparation.
 
 Concrete interface decisions and the selected distribution approach are recorded
-in the completed [implementation plan](implementation.md). They do not expand
+in that completed historical plan. They do not expand
 the product into conversations, follow-up messages, application-owned semantic
 retry loops, prepared-handle coordination, or multi-step workflows.

go.mod

@@ -3,13 +3,13 @@ module gitea.maximumdirect.net/eric/scriptorium
 go 1.25.5
 
 require (
-	gitea.maximumdirect.net/eric/ConfigKit v0.4.0
-	gitea.maximumdirect.net/eric/promptkit v0.11.0
+	gitea.maximumdirect.net/eric/ConfigKit v0.4.2
+	gitea.maximumdirect.net/eric/promptkit v0.11.2
 )
 
 require (
-	gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1 // indirect
-	gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0 // indirect
+	gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 // indirect
+	gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0 // indirect
 	github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect
 	go.yaml.in/yaml/v4 v4.0.0-rc.6 // indirect
 	golang.org/x/text v0.14.0 // indirect

go.sum

@@ -1,11 +1,11 @@
-gitea.maximumdirect.net/eric/ConfigKit v0.4.0 h1:fo+vKff3zTGeWqJIA38NtT84b6OUP//9ZmBH3lFuKgk=
-gitea.maximumdirect.net/eric/ConfigKit v0.4.0/go.mod h1:tYWpsrbLyu05r8+1MapWp5fN6ZrX9I8hU2xEPedYmYk=
-gitea.maximumdirect.net/eric/promptkit v0.11.0 h1:x7JguOUiInPVXK0GEitjyoRFqqvcuSTjYUvqJ+whtik=
-gitea.maximumdirect.net/eric/promptkit v0.11.0/go.mod h1:0zEBVlJJC+ldDdXazAgybYBXNSe74vwFx5dyOuSos/w=
-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.20260922.1/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.20260922.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
+gitea.maximumdirect.net/eric/ConfigKit v0.4.2 h1:ZMxmv8pOnLtAx2hFTf8Z+pHKUbR89xErkBhwjr4yK24=
+gitea.maximumdirect.net/eric/ConfigKit v0.4.2/go.mod h1:tYWpsrbLyu05r8+1MapWp5fN6ZrX9I8hU2xEPedYmYk=
+gitea.maximumdirect.net/eric/promptkit v0.11.2 h1:2RqI+KtflvSh7vLQaTAQCmMaFQscEA7EPwPazyvXRoY=
+gitea.maximumdirect.net/eric/promptkit v0.11.2/go.mod h1:onm/FBPUKQ8/NSPwTEk26Ut+dVX2iXcq8vEseB+g/0E=
+gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 h1:wdab+R+lgMZxzYwhbAuCrW7zdSQ1cW9ovBR6UzLmZR4=
+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.20260926.0 h1:baCCIB6Ee5t0S4Zc++NTBIPcJEv5UPS6DlSrpZfykwg=
+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=