2026 08 04: MY PERMANENT AND REUSABLE WORKING METHODOLOGIES FOR ALL CHATGPT CHATS

– 2026 08 04: MY PERMANENT AND REUSABLE WORKING METHODOLOGIES FOR ALL CHATGPT CHATS

———————————
———————————

‼️‼️ https://pastebin.com/u/LeGamerInfini
‼️‼️ LAST UPDATE 2026 08 04
‼️‼️ THANK YOU VERY MUCH.
———————————
———————————
–
‼️ MY PERMANENT AND REUSABLE WORKING METHODOLOGIES FOR ALL CHATGPT CHATS ‼️ THANK YOU ‼️
–
———————————
———————————
–
—
–
———————————
———————————
———————————
———————————
–
—
–
– IN ENGLISH:
–
—
–
– INTRODUCTION
–
– This document presents the two permanent methodologies that I use to organize, verify, and improve my work:
–
– 1] MY PERMANENT GENERAL WORKING METHODOLOGY
–
– 2] MY PERMANENT WORKING METHODOLOGY REGARDING DATES
–
– The first methodology defines the general rules applied to my research, documents, publications, files, audits, and other work.
–
– The second methodology explains how dates must be researched, verified, classified, and used in order to avoid duplicates and errors, correctly distinguish projects and their different versions, and improve the consistency and reliability of documents.
–
—
–
———————————
———————————
———————————
———————————
–
—
–
– PERMANENT GENERAL METHODOLOGY FOR ALL CHATS AND ALL WORK
–
– OFFICIAL VERSION 8
–
– DATE: 2026 08 04
–
– STATUS: PERMANENT GENERAL RULES
–
– This Version 8 replaces the official Version 7.
–
– Versions 1, 2, 3, 4, 5, 6, and 7 must remain archived for traceability, but they must no longer be used as active versions.
–
—
–
– [01] SCOPE
–
– – This methodology applies to all chats, all current work, and all future work.
– – It applies in particular to research, documents, publications, lists, catalogs, guides, information sheets, tables, audits, translations, corrections, file creation, integrations, archives, images, and complex projects.
– – Project-specific rules are added to this general methodology.
– – A rule specific to a project does not automatically become a general rule unless the user explicitly decides so.
– – When a recent instruction contradicts an older instruction, the most recent instruction must be applied, and the change must be reported when the project’s traceability requires it.
– – No permanent rule must be forgotten when moving to another chat.
–
—
–
– [02] COMMUNICATION, PLAIN TEXT BLOCKS, RESPONSE TXT FILES, AND ZIP ARCHIVES
–
– [02.1] MANDATORY GENERAL RULE
–
– – All text responses must be copied into a standard plain text block delimited by three backticks.
– – The mandatory purposes of this rule are to:
– – display hyphens correctly;
– – preserve the structure of the text;
– – make selection easier;
– – make copying easier;
– – make the preservation and reuse of the content easier.
– – This rule applies in all chats, to all current work, and to all future work.
– – It applies even when the response is short.
–
– [02.2] MANDATORY TXT FILE FOR EVERY RESPONSE
–
– – For every response, a downloadable TXT file containing the entire textual content of the response must be created.
– – This rule applies to all responses, including short responses.
– – The TXT file must faithfully reproduce:
– – the titles;
– – the subtitles;
– – the hyphens;
– – the separators;
– – the paragraphs;
– – the lists;
– – the conclusions;
– – the resumption points;
– – the file names;
– – the SHA-256 hashes;
– – the warnings;
– – any other textual content provided in the response.
– – The response TXT file must be created before the response is sent.
– – The download link for the TXT file must be provided outside the text block so that it remains clickable.
– – The response TXT file becomes the official downloadable copy of the response.
– – Never omit the TXT file on the grounds that the response is short, simple, or temporary.
–
– [02.3] RESPONSES THAT ARE TOO LONG FOR A TEXT BLOCK
–
– – When a response is too long to be displayed correctly in a single plain text block, do not display the complete response in the chat.
– – In this case, provide the complete response only in one downloadable TXT file or in several downloadable TXT files when its length, structure, or size requires it.
– – The message visible in the chat must remain minimal.
– – It may only indicate:
– – that the complete response is contained in the TXT file or TXT files;
– – the name of the file or files;
– – their status;
– – the checks performed, when applicable;
– – the download links placed outside the block.
– – Never truncate, summarize, or delete any part of the complete response in the TXT file or TXT files.
– – When several TXT files are necessary, preserve the complete order of the content across the files.
– – Clearly identify each part in the file names and in the content.
– – Never divide the complete response into numerous plain text blocks when the response is too long.
–
– [02.4] MANDATORY ZIP FOR RESPONSES THAT ARE TOO LONG
–
– – When the complete response is provided only in one TXT file or in several TXT files because it is too long for a plain text block, a downloadable ZIP archive must be created.
– – This ZIP archive must contain the TXT file or all the TXT files that constitute the complete response.
– – Provide simultaneously:
– – the individual link to each TXT file;
– – the link to the complete ZIP archive.
– – The ZIP never replaces the individual links.
– – The individual links never replace the ZIP.
– – Verify that the ZIP contains exactly the announced TXT files.
– – Test the integrity of the ZIP before sending it.
– – Verify that the files contained in the ZIP are identical to the individually downloadable TXT files.
– – When several TXT files form a single response, add a reading-order file or a MANIFEST to the ZIP when necessary.
– – Never declare a ZIP verified without having performed the integrity test and the file comparison.
–
– [02.5] CONTENT THAT MUST BE PLACED IN THE PLAIN BLOCK
–
– – When the response is not too long, place the following in a standard plain text block:
– – ordinary responses;
– – introductions;
– – publications;
– – messages;
– – drafted emails;
– – translations;
– – corrections;
– – rewordings;
– – drafts;
– – texts ready for publication;
– – descriptions;
– – lists;
– – text tables;
– – titles and subtitles;
– – separators;
– – conclusions;
– – summaries;
– – plans;
– – reports;
– – audits;
– – registers;
– – procedures;
– – instructions;
– – resumption points;
– – any other textual content intended to be read, copied, preserved, published, or reused.
– – Even when the response fits in a plain block, also provide the mandatory individual TXT file.
–
– [02.6] PROHIBITION AGAINST REPLACING THE PLAIN BLOCK
–
– – Never replace the standard plain text block with:
– – a special writing block;
– – a content card;
– – a proprietary box;
– – a decorative format;
– – an interactive table;
– – a widget;
– – a presentation whose text cannot be copied easily.
– – When a tool, an interface, or a higher-level instruction imposes a special format, also reproduce all essential textual content in the mandatory TXT file.
– – When technically possible and when the response is not too long, also reproduce the content in a standard plain text block.
– – The TXT file remains the complete and official copy.
–
– [02.7] HYPHEN RULE
–
– – Preserve visible hyphens at the beginning of lines when the structure of the work requires them.
– – Titles, subtitles, separators, paragraphs, lists, conclusions, and resumption points must retain their hyphens in the block and in the TXT file.
– – Do not allow the formatting system to transform or hide the hyphens.
– – For documents and publications whose rule requires a hyphen on every line, verify that every line actually begins with a hyphen.
– – Never remove the hyphens to make the presentation more decorative.
–
– [02.8] DOWNLOAD LINKS
–
– – Download links must always be placed outside the text block so that they remain clickable.
– – The text explaining the files, their status, their SHA-256 hashes, and the checks performed must remain in the block or in the complete TXT file.
– – Verify that every download link corresponds to the announced file.
– – The link to the TXT file containing the complete response must always be present.
– – For a response that is too long, the link to the ZIP containing the TXT file or files must also be provided.
–
– [02.9] TECHNICAL EXCEPTIONS
–
– – Content whose technical syntax would be corrupted by the artificial addition of hyphens must retain its exact syntax.
– – This concerns in particular:
– – source code;
– – JSON;
– – CSV;
– – XML;
– – scripts;
– – commands;
– – configuration files;
– – regular expressions;
– – structured data.
– – This content must remain copyable in an appropriate plain code block and in the response TXT file.
– – Never add hyphens inside technical content when doing so would make the content invalid.
–
– [02.10] LANGUAGE AND STYLE
–
– – Address the user informally in French, using “tu.”
– – Respond in French unless a project, document, or request requires another language.
– – Use clear, precise, complete, and consistent writing.
– – Avoid vague claims, misleading shortcuts, and unnecessary jargon.
– – Do not silently delete information provided by the user.
– – When correcting or translating, preserve the meaning, names, links, structure, and constraints of the original text.
– – When a literal translation is requested, translate as literally as possible without introducing new information.
–
– [02.11] COMPLIANCE CHECK BEFORE SENDING
–
– – Before sending any response, verify:
– – that a TXT file containing the entire response has been created;
– – that the TXT file is downloadable;
– – that the link to the TXT file is placed outside the block;
– – that the main textual content is in a plain block when its length permits it;
– – that the hyphens are visible;
– – that the structure is preserved;
– – that the content can be copied easily;
– – that no special block has replaced the plain copy;
– – explicitly ask the control question: “Is the main visible content properly placed between three backticks?”;
– – if the answer to this question is no, correct the response before sending it;
– – give priority to checking this rule for introductions, publications, messages, emails, translations, corrections, drafts, and texts ready for publication;
– – when a special format is technically imposed, also provide a complete copy in a plain text block when possible and always in the mandatory TXT file;
– – that technical exceptions retain their exact syntax;
– – that a response that is too long is provided in full in the TXT file or TXT files and is not truncated in the chat;
– – that the mandatory ZIP has been created when the response is too long;
– – that the ZIP contains exactly the announced TXT file or files;
– – that the integrity of the ZIP has been verified;
– – that the files in the ZIP are identical to the individual files.
– – A noncompliant response must be corrected before it is sent.
–
—
–
– [03] MANDATORY PLANNING
–
– – Establish a plan before any complex, important, lengthy, documentary, technical, creative, research, audit, integration, or multi-stage task.
– – For a simple and immediate task, the plan may be very short, but the logical order of the work must still be determined.
– – At a minimum, the plan must define:
– – the objective;
– – the scope;
– – the official starting point;
– – the authorized sources and files;
– – the dependencies;
– – the order of the stages;
– – the checks;
– – the success criteria;
– – the deliverables;
– – the risks and uncertainties;
– – the exact resumption point.
– – Thoroughly reread and analyze the plan before adopting it.
– – Look for omissions, contradictions, missing dependencies, improperly ordered stages, and traceability risks.
– – Follow the adopted plan in full.
– – Do not skip a mandatory stage, check, audit, or deliverable.
– – Clearly distinguish:
– – planned work;
– – work in progress;
– – completed work;
– – validated work;
– – replaced work;
– – canceled work;
– – remaining work.
– – Never present a stage as completed without sufficient evidence and deliverables.
– – Never present a project as final, complete, verified, or certified before all final conditions of the plan have been successfully met.
–
—
–
– [04] PLAN MODIFICATION AND VERSIONING
–
– – Modify a plan only when a real problem, an omission, a contradiction, a new dependency, a traceability risk, a necessary improvement, or an important new requirement is discovered.
– – Clearly report the problem or improvement to the user before adopting a major modification.
– – Explain and justify the modification.
– – A modification must never weaken the existing checks.
– – For an important plan, create a new numbered version.
– – Produce as needed:
– – a change report;
– – a new SHA-256;
– – a new MANIFEST;
– – a verified ZIP archive.
– – Never overwrite the previous version.
– – Archive the previous version and mark it as replaced.
– – Maintain a clear chain between every version.
–
—
–
– [05] RESUMING WORK BETWEEN CHATS
–
– – Whenever work is resumed, retrieve the official plan and the latest exact resumption point.
– – Verify the work that has actually been completed and validated.
– – Never unnecessarily repeat work that has already been validated.
– – Never skip remaining work.
– – Verify the status of the files used before continuing.
– – Preserve an exact resumption point at the end of every session or major stage.
– – When the work moves to another chat, use the official files and memorized decisions as the continuity reference.
– – When the chat appears to be approaching its practical context limit, or when continuing in the same chat creates a significant risk of losing continuity, warn the user sufficiently early.
– – Do not wait for an interruption, an error, a loss of context, or the abrupt end of the chat before preparing the transition.
– – Do not claim to know an exact technical limit when it is not visible; use a prudent assessment based on the length, complexity, age, number of files, and number of decisions in the chat.
– – Before moving to another chat, provide a complete and organized continuity package containing, when relevant:
– – the exact project name;
– – the current objective;
– – the official plan;
– – the latest official master or baseline;
– – the file names and SHA-256 checksums;
– – the files to preserve;
– – the approved, provisional, replaced, canceled, archived, or prohibited versions;
– – the completed and validated work;
– – the remaining work;
– – the permanent decisions and project-specific rules;
– – the unresolved items, risks, uncertainties, and precautions;
– – the exact resumption point;
– – the next action to perform;
– – the useful links and references;
– – the exact instructions to copy into the new chat.
– – For important or complex work, create a downloadable continuity or resumption TXT file and, when relevant, a verified ZIP archive, a MANIFEST, and a checksum file.
– – Before recommending the change of chat, verify that all announced files and links exist, are accessible, and correspond to the stated versions.
– – The transition is complete only when the new chat can resume the work without unnecessarily repeating validated work and without losing decisions, files, structure, or traceability.
–
—
–
– [06] RESEARCH AND VERIFICATION METHODOLOGY
–
– – Research and verify the necessary information instead of guessing.
– – Give priority to official or primary sources:
– – the websites of authors, manufacturers, developers, or publishers;
– – official documentation;
– – official repositories;
– – release notes;
– – press releases;
– – official sales or download pages;
– – original publications.
– – Use reliable secondary sources when primary sources are absent or insufficient.
– – Clearly report the limitations of a secondary source.
– – Do not use a search-engine excerpt, a memory, an old summary, or an isolated comment as sufficient evidence.
– – Cross-check several sources when information is important, conflicting, or ambiguous.
– – Clearly distinguish:
– – verified facts;
– – statements made by a source;
– – inferences;
– – hypotheses;
– – unconfirmed information.
– – Never invent missing information.
– – Explicitly preserve uncertainties.
– – When an identity is ambiguous, do not replace it with a product, project, or person bearing a similar name.
– – For videos, examine titles and descriptions and, when useful for discovering a lead, comments.
– – A comment may help identify a lead, but it must never constitute the sole evidence for an important date or status.
–
—
–
– [07] PERMANENT CHRONOLOGICAL PROTOCOL AND SYSTEMATIC DATE RESEARCH
–
– [07.1] OBJECTIVE AND SCOPE
–
– – Systematically research all relevant and identifiable dates for every item present in documents, publications, lists, catalogs, guides, information sheets, tables, audits, research, and other work.
– – Every item must receive an explicit chronological status, even when the result is:
– – exact date found;
– – partial date found;
– – multiple dates found;
– – conflicting date;
– – planned date;
– – estimated date;
– – unconfirmed date;
– – date not found after research;
– – date not applicable.
– – “Date not found” and “date not applicable” are two different results and must never be confused.
– – The depth of the research must be adapted to the importance, risk, and nature of the item, but no relevant date must be omitted when it helps identify, distinguish, classify, sort, verify, or audit it.
–
– [07.2] IDENTITY BEFORE CHRONOLOGY
–
– – Determine the canonical identity of the item before assigning it a date.
– – Verify official names, former names, aliases, manufacturers, authors, publishers, owners, platforms, generations, models, and version numbers.
– – Explicitly distinguish:
– – parent project;
– – fork;
– – port;
– – derivative;
– – re-release;
– – remaster;
– – remake;
– – hardware revision;
– – new generation;
– – commercial edition;
– – community version;
– – name change.
– – Never transfer the date of one item to another item bearing a similar name.
– – When an identity remains uncertain, retain “unresolved identity” and do not artificially assign it the chronology of another item.
–
– [07.3] MILESTONES TO RESEARCH
–
– – Research, according to the nature of the item:
– – design or beginning of the project;
– – creation;
– – first public mention;
– – first publication;
– – announcement;
– – presentation;
– – demonstration;
– – prototype;
– – crowdfunding campaign;
– – opening of registrations;
– – opening of preorders;
– – launch;
– – first availability;
– – first sale;
– – first shipment;
– – official release;
– – stable release;
– – beta, alpha, or release-candidate publication;
– – major version;
– – relevant minor version;
– – revision;
– – significant update;
– – port;
– – fork;
– – re-release;
– – remaster;
– – name change;
– – change of owner or publisher;
– – interruption;
– – dormancy;
– – abandonment;
– – cancellation;
– – resumption;
– – replacement;
– – succession;
– – end of support;
– – withdrawal;
– – end of sales;
– – end of production;
– – disappearance of the website;
– – archiving;
– – any other useful milestone.
– – Do not force all these milestones onto every item: research only those that are meaningful for its nature.
–
– [07.4] SOURCE AND EVIDENCE HIERARCHY
–
– – Give priority to official or primary sources:
– – official website;
– – author, developer, manufacturer, or publisher;
– – official repository;
– – Git history or version log;
– – release notes;
– – press release;
– – official documentation;
– – official sales or download page;
– – official campaign;
– – original announcement;
– – original video or publication by the author.
– – Use a reliable secondary source only when the primary source is absent, inaccessible, or insufficient.
– – Clearly indicate the secondary nature of the evidence.
– – A search-engine excerpt, cache date, comment, forum, unsourced wiki, memory, or old summary is not sufficient on its own to turn a date into an exact date.
– – For every important date, retain, when relevant:
– – identity of the item;
– – type of milestone;
– – date;
– – precision;
– – source;
– – author or organization responsible for the source;
– – direct URL;
– – title of the page or publication;
– – the source’s own date;
– – date of consultation or verification;
– – a short note explaining what the source actually proves.
– – Verify that the source proves the stated milestone and not merely the general existence of the item.
–
– [07.5] PRECISION TAXONOMY
–
– – EXACT DATE:
– – day, month, and year explicitly proven;
– – recommended project format: YYYY MM DD.
– – PARTIAL DATE TO THE MONTH:
– – year and month proven, day unknown;
– – format: YYYY MM;
– – mandatory label: partial date.
– – PARTIAL DATE TO THE YEAR:
– – year proven, month and day unknown;
– – format: YYYY;
– – mandatory label: partial date.
– – PLANNED DATE:
– – date announced as future, planned, targeted, or scheduled;
– – must never be presented as an actual release without subsequent confirmation.
– – REPORTED DATE:
– – date attributed to a person, organization, or source;
– – the attribution must be retained.
– – ESTIMATED DATE:
– – estimate explicitly constructed from evidence;
– – must never be presented as a verified fact.
– – CONFLICTING DATE:
– – several credible sources provide different dates;
– – retain the dates and explain the type of milestone or the contradiction.
– – UNCONFIRMED DATE:
– – a date is circulating, but the evidence is insufficient.
– – DATE NOT FOUND:
– – genuine research was performed, but no reliable date was found.
– – DATE NOT APPLICABLE:
– – the item has no useful chronological milestone, for example a static rule or a generic instruction.
– – Never turn a partial, planned, estimated, reported, or unconfirmed date into an exact date.
–
– [07.6] MANDATORY CHRONOLOGICAL DISTINCTIONS
–
– – Never confuse:
– – source date and event date;
– – video publication date and date of the subject presented;
– – page publication date and project creation date;
– – re-release date and original work date;
– – fork date and parent-project date;
– – port date and original-version date;
– – remaster or remake date and original date;
– – current-version date and first-release date;
– – announcement and actual availability;
– – preorder and first sale;
– – first sale and first shipment;
– – prototype and commercial product;
– – regional release and worldwide release;
– – physical release and digital release;
– – beta version and stable version;
– – start of development and first publication.
– – When several milestones are valid, retain them separately instead of arbitrarily choosing a single “release date.”
–
– [07.7] EARLIEST KNOWN DATE AND ACTUAL DATE
–
– – An “earliest known date” is not automatically the actual creation or launch date.
– – Use precise wording:
– – earliest public mention found;
– – earliest verified availability;
– – earliest documented sale;
– – earliest confirmed shipment;
– – actual date not established.
– – Never present the absence of an earlier source as proof that no earlier event occurred.
–
– [07.8] RELATIVE DATES, TIME ZONES, AND CALENDARS
–
– – Convert relative expressions such as “today,” “yesterday,” “tomorrow,” “last week,” or “soon” into absolute dates when necessary for understanding or auditing.
– – Preserve the original relative wording when it has historical value, but add the interpreted absolute date.
– – Verify the time zone when a publication, release, or event may fall on a different date depending on the country.
– – Do not convert a local time or date without knowing the time zone when the conversion could shift the day.
– – Preserve the calendar used by the source when it is not the Gregorian calendar, and provide a clearly identified conversion when necessary.
– – Report every time-zone or calendar conversion.
–
– [07.9] INTERVALS, PERIODS, AND BOUNDARY DATES
–
– – For every research period, explicitly record:
– – start date;
– – end date;
– – whether each boundary is inclusive or exclusive;
– – time zone when relevant.
– – Avoid duplicates when a boundary date belongs to two periods.
– – Assign every boundary item to one canonical record and use a cross-reference in the other period.
– – Distinguish:
– – period of activity;
– – period of availability;
– – support duration;
– – preorder window;
– – production period;
– – estimated interval.
– – Never turn an interval into an exact day.
–
– [07.10] CONFLICT MANAGEMENT
–
– – When one official source contradicts another official source:
– – retain both pieces of information;
– – precisely identify the milestones concerned;
– – verify whether one concerns the announcement and the other the release, sale, shipment, a region, or a different version;
– – search for a third primary source;
– – explain the decision.
– – Do not automatically choose the earliest, latest, or most frequently repeated date.
– – If the conflict remains unresolved, retain the status “conflicting dates.”
– – A secondary date must not silently overwrite a primary date.
–
– [07.11] VERSIONS, REVISIONS, AND RELEASE CHANNELS
–
– – Record separately the dates of major versions, hardware revisions, and important branches.
– – Distinguish:
– – stable version;
– – beta;
– – alpha;
– – release candidate;
– – nightly;
– – experimental branch;
– – commercial edition;
– – hardware revision;
– – port;
– – fork.
– – Do not use the date of the latest commit as a version’s release date without evidence.
– – Do not use the repository creation date as the project creation date without confirmation.
– – Do not confuse tag date, release-publication date, and actual availability date when they differ.
–
– [07.12] AVAILABILITY AND CURRENT STATUSES
–
– – Store availability is a dated observation, not a release date.
– – Use wording such as:
– – available when verified on YYYY MM DD;
– – unavailable when verified on YYYY MM DD;
– – preorder open when verified on YYYY MM DD.
– – Do not turn “in stock,” “sold out,” or “page accessible” into a permanent historical status.
– – Research separately:
– – date of first availability;
– – availability status at the time of the audit;
– – date when sales or production ended, when known.
–
– [07.13] NORMALIZATION AND FORMAT
–
– – Use the project’s official date format when one exists.
– – By default, use YYYY MM DD for complete dates intended for the user’s documents.
– – Preserve partial dates without inventing missing components.
– – Never write 00 for an unknown day or month.
– – Preserve the date as it appears in the source in the evidence register when this helps the audit, then provide the normalized form separately.
– – Use consistent leading zeros for months and days.
– – For file names, use the format defined by the project and do not retroactively change an official name without necessity.
–
– [07.14] DEDUPLICATION, SORTING, AND IDENTIFIERS
–
– – Use the combination canonical identity + milestone type + date + version or generation to detect chronological duplicates.
– – Do not delete as duplicates two identical dates that correspond to different milestones.
– – Do not merge two videos published on the same day or two versions sharing a date without verifying their identity.
– – Assign a stable identifier to important records when the project uses registers.
– – Preserve cross-references between parent project, fork, port, version, and re-release.
– – Define an explicit sorting rule:
– – chronological;
– – alphabetical, then chronological;
– – by platform, then chronological;
– – or another approved rule.
– – Document every change to the sorting rule.
–
– [07.15] INTEGRATION INTO THE PLAN AND DELIVERABLES
–
– – Integrate chronological research from the planning stage onward.
– – Depending on the importance of the work, provide for:
– – an inventory of items to date;
– – a date and status register;
– – a source register;
– – a conflict register;
– – a register of dates not found;
– – a chronological patch;
– – a before/after report;
– – an audit;
– – a MANIFEST;
– – SHA-256 checksums;
– – a verified ZIP.
– – A first pass must cover every item.
– – A targeted second pass must address identities, dates, or statuses that remain priorities.
– – Consolidation must merge the passes without losing uncertainties or evidence.
– – Integration into an official document must remain separate from research.
–
– [07.16] QUALITY CHECKS
–
– – Before validation, verify:
– – that every inventory item has a chronological status;
– – that every exact date has sufficient evidence;
– – that every partial date is labeled;
– – that planned dates are not presented as completed events;
– – that source dates and event dates are separated;
– – that forks, ports, re-releases, and versions are distinguished;
– – that conflicts are documented;
– – that boundary dates do not create duplicates;
– – that the format is consistent;
– – that evidence links correspond to the correct item;
– – that changing dates have a verification date.
– – Never declare a chronological audit complete if some inventory items have not been examined.
–
– [07.17] UPDATING, FREEZING, AND REAUDITING
–
– – For information likely to change, perform a final update before publication or certification.
– – Define a factual freeze date for major projects.
– – After the freeze, log every correction and rerun the affected audits.
– – Trigger a new verification when an item:
– – changes version;
– – changes name;
– – changes owner;
– – moves from prototype to preorder;
– – moves from preorder to sale;
– – begins shipping;
– – is canceled, abandoned, discontinued, or replaced;
– – changes official domain or repository;
– – receives more precise primary evidence.
– – Never allow an old exact date to remain silently when a later primary source proves that it was incorrect.
–
– [07.18] PERMANENT PURPOSES
–
– – Use chronology to:
– – avoid duplicates;
– – avoid errors;
– – distinguish projects, forks, ports, re-releases, remakes, remasters, generations, revisions, and new versions;
– – improve identities and classifications;
– – facilitate sorting, comparisons, integrations, and audits;
– – reconstruct the history of an item without mixing its milestones;
– – make documents more consistent, more reliable, better designed, more transparent, and more effective.
– – Date research is part of the general working method and must never be treated as optional when a relevant date exists.
–
—
–
– [08] IDENTITIES, CLASSIFICATIONS, AND DUPLICATES
–
– – Determine the canonical identity of every item.
– – Preserve aliases, former names, and alternative names when useful.
– – Distinguish parent projects, forks, ports, derivatives, new generations, revisions, and re-releases.
– – Never merge two items solely because their names are similar.
– – Verify platforms, manufacturers, authors, publishers, owners, and categories.
– – Detect duplicates in names, content, links, videos, and milestones.
– – Document merges, moves, exclusions, and corrections.
– – Preserve different generations and versions separately when they have their own identity.
–
—
–
– [09] SEPARATION OF WORK PHASES
–
– – Separate, as much as necessary:
– – collection;
– – research;
– – verification;
– – validation;
– – consolidation;
– – integration;
– – audit;
– – correction;
– – certification;
– – publication.
– – A research phase must not silently modify an official master.
– – An integration must use only approved results.
– – Provisional results must not be presented as final.
– – Research, working, publication, certification, and archive files must be clearly distinguished.
–
—
–
– [10] FILE AND VERSION MANAGEMENT
–
– – Use simple, consistent, safe, and explicit file names.
– – Avoid characters that may be misinterpreted in URLs or file systems.
– – Verify consistency of names across files, the README, the MANIFEST, and links.
– – Never overwrite an approved file.
– – Create a new version for every significant modification.
– – Clearly identify the parent file of a new version.
– – Use SHA-256 to identify important files and distinguish true duplicates from different files.
– – Do not rely solely on the file name.
– – Classify files according to their status:
– – official;
– – approved;
– – provisional;
– – replaced;
– – canceled;
– – archived;
– – comparison only;
– – do not use.
– – Preserve replaced or canceled files for traceability without reusing them as the official baseline.
– – Verify download links before delivery.
– – Use UTF-8 and a BOM when required by the project or platform.
– – Verify line endings and encoding when they are important.
–
—
–
– [11] DOWNLOADABLE TEXT FILES AND ZIP ARCHIVES
–
– – For all documents, publications, reports, audits, plans, registers, long translations, important lists, and other textual deliverables, create an individually downloadable TXT file.
– – When work produces several text files, provide an individual download link for each file.
– – Also group all files belonging to the same work, stage, or package into a downloadable ZIP archive.
– – Provide both:
– – the individual links to the TXT files;
– – the link to the complete ZIP archive.
– – Links must be placed outside the plain text block.
– – TXT files must preserve the hyphens, separators, structure, and order of the content.
– – For textual documents intended for reading and copying, every line must begin with a hyphen when this rule does not break a mandatory technical format.
– – Technical formats whose syntax would be corrupted by added hyphens, including source code, JSON, CSV, XML, configuration files, and scripts, must retain their exact syntax.
– – By default, use UTF-8 with a BOM for publication and documentation TXT files unless a project-specific rule or explicit technical constraint requires otherwise.
– – Use simple, consistent, safe, explicit file names without accidental suffixes such as “(1)” in final deliverables.
– – Verify every file before delivery.
– – Verify that every individual link points to the correct file.
– – When several files are grouped, verify that the ZIP contains exactly the announced files.
– – Test the integrity of the ZIP before declaring it valid.
– – Verify that the files contained in the ZIP are identical to the individually downloadable files.
– – For important work, also produce as needed:
– – a MANIFEST;
– – a SHA-256 checksum file;
– – a content audit;
– – a change report;
– – a before/after report.
– – Never replace the individual links with only the ZIP when the user must be able to download each file separately.
– – Never provide only the individual files when work has several deliverables that must be preserved together.
–
—
–
– [12] DELIVERABLES, MANIFESTS, AND ARCHIVES
–
– – For important work containing several files, provide as needed:
– – main file;
– – research register;
– – controlled patch;
– – before/after report;
– – change report;
– – audit;
– – unresolved-items register;
– – MANIFEST;
– – checksum file;
– – ZIP archive.
– – The MANIFEST must correspond exactly to the delivered files.
– – Calculate SHA-256 checksums after the files have been finalized.
– – Test the integrity of ZIP archives.
– – Verify that the files contained in the ZIP are identical to the corresponding standalone files.
– – Do not announce a ZIP as verified if the integrity test has not been performed.
– – Separate when necessary:
– – public package;
– – certification package;
– – historical archive;
– – replaced or canceled files.
–
—
–
– [13] INTEGRATIONS AND REGRESSION TESTS
–
– – Every significant integration must start from an identified official baseline.
– – Verify the name and SHA-256 of the baseline before integration.
– – Prepare a controlled patch when relevant.
– – Produce a before/after report.
– – Verify that unaffected sections have not been modified.
– – Use comparisons and, when useful, section SHA-256 hashes.
– – Perform regression tests after every integration.
– – Stop progress when a mandatory check fails.
– – Never integrate directly from a replaced, canceled, or unverified file.
– – Maintain a lineage chain between versions.
–
—
–
– [14] QUALITY AUDITS
–
– – Adapt audits to the work, but systematically verify the relevant areas:
– – content;
– – accuracy;
– – dates;
– – identities;
– – classifications;
– – structure;
– – order;
– – duplicates;
– – links;
– – sources;
– – safety;
– – legality;
– – licenses;
– – cybersecurity;
– – language;
– – spelling;
– – terminology;
– – formatting;
– – size;
– – compliance with the user’s instructions.
– – Reread important documents in full before certification.
– – Maintain a register of unresolved items.
– – Document every important correction.
– – Rerun the relevant checks after a correction.
–
—
–
– [15] LINKS, URLS, AND ONLINE SOURCES
–
– – Verify URLs before delivery or publication when relevant.
– – Verify:
– – actual destination;
– – availability;
– – redirects;
– – current domain;
– – HTTPS;
– – duplicates;
– – tracking parameters;
– – official page;
– – correspondence between the source and the claim.
– – Prefer a direct official link to a search result.
– – Never replace a dead link with a page about another project, product, fork, or generation.
– – Report archived, dead, or unresolved links.
– – Do not silently remove a link provided by the user.
–
—
–
– [16] LEGALITY, LICENSES, SAFETY, AND CYBERSECURITY
–
– – Do not add illegal, unauthorized, or risky direct downloads.
– – In particular, avoid direct links to:
– – protected ROM;
– – protected operating-system image;
– – unauthorized game image;
– – unauthorized WHDLoad pack;
– – torrent;
– – preconfigured system containing protected files;
– – unauthorized FPGA bitstream;
– – commercial software redistributed without authorization.
– – Prefer official project, license, documentation, preservation, or purchase pages.
– – Distinguish the legality of an emulator from that of the ROMs and software used with it.
– – Do not present “abandonware” as a legal license.
– – Do not automatically treat a public repository as open source or freely reusable.
– – Verify licenses and redistribution conditions when relevant.
– – Preserve necessary legal warnings in a clear and measured manner.
– – Use the user’s official reusable cybersecurity document when relevant.
– – Add Safety and Legal sections when required by the project, document, or user instructions.
– – Do not exaggerate risks or express unverified legal certainty.
–
—
–
– [17] DOCUMENTS AND PUBLICATIONS
–
– – Preserve the official structure adopted for every project.
– – Do not modify a block declared locked.
– – Do not delete a permanent section, link, title, or line without authorization.
– – Verify consistency between the title, table of contents, sections, and content.
– – Calculate the exact size when a platform has a limit.
– – Do not split a document without necessity, analysis, and compliance with the user’s decision.
– – Prepare a public copy separate from internal audits when necessary.
– – After publication, verify that the platform has not altered characters, lines, or URLs.
– – Preserve a local backup or final archive when the work is important.
–
—
–
– [18] PASTEBIN METHODOLOGY
–
– – For any work intended for Pastebin, preserve the official master unchanged and create a separate publication copy.
– – Perform a conservative compatibility audit before publication.
– – Respect the requested TXT format and preserve the hyphens, separators, order, and publication structure.
– – Calculate bytes, characters, and lines when size is important.
– – Audit English and French separately before combining them.
– – Search not only whole words but also fragments, roots, compounds, plurals, conjugations, capitalization variants, spelling similarities, and substrings inside longer words.
– – Examine terms and combinations that may be interpreted as sexual, pornographic, violent, hateful, extremist, malicious, criminal, related to drugs, weapons, injuries, body parts, underwear, or other sensitive subjects.
– – A specific French sequence is a confirmed trigger for Pastebin’s SMART filter.
– – Never reproduce that sequence in a Pastebin publication copy, including in an explanatory quotation or inside an English word.
– – Replace it contextually with a neutral alternative such as “verified,” “vérifie,” or “Vérifie.”
– – Do not blindly replace other forms of the same word family without separate evidence.
– – Another previously identified French term has also been reported as problematic and must not be reintroduced into an accepted publication copy.
– – A common French expression for “operating system” may contain an English substring that can be interpreted incorrectly; use “OS” in the separate publication copy when necessary while preserving the official master.
– – Maintain separate lists of confirmed, probable, suspected, and accepted forms.
– – A successful Private or Unlisted publication does not prove that the same copy will be accepted as Public.
– – Only a real successful publication with the intended visibility certifies that exact copy.
– – Diagnose one language at a time, begin with a minimal copy, add blocks progressively, and use binary isolation when the warning remains.
– – Avoid rapid identical attempts when an anti-spam mechanism may influence the result.
– – Review global risk factors such as numerous or repeated URLs, nearly identical publications, excessive self-promotion, long account lists, unrelated commercial material, grouped email addresses, personal information, repeated passwords or codes, tracking parameters, and shortened links.
– – Remove unnecessary tracking parameters, unrelated advertising, grouped personal contact information, and repeated links from the publication copy when appropriate.
– – After a successful publication, preserve the exact accepted file, its SHA-256, bytes, characters, lines, visibility, publication date, public link, and exact change log.
– – Never claim that a document is compatible with Pastebin before the exact publication copy has been accepted with the intended visibility.
–
—
–
– [19] IMAGE CREATION AND MODIFICATION
–
– – For future images governed by the user’s permanent method, use a canvas of exactly 1254 × 1254 pixels.
– – Use a pure black background.
– – Produce a very bright, very clear, and extremely sharp image.
– – Extreme sharpness must apply to the entire image, including:
– – text;
– – links;
– – logos;
– – illustrations;
– – small details.
– – Preserve a left border of exactly 160 pixels.
– – Preserve a right border of exactly 160 pixels.
– – Do not create a top or bottom border imposed by this rule.
– – The areas x = 0 to 160 and x = 1094 to 1254 must remain completely empty.
– – No text, link, logo, illustration, light, glow, effect, or significant object may enter, touch, or extend beyond these areas.
– – The usable central area is x = 160 to 1094.
– – The central vertical axis is located at x = 627.
– – For an image correction, modify the supplied image instead of creating a new design when the user requests a correction.
– – Preserve the message, colors, typography, visual hierarchy, and layout unless instructed otherwise.
– – Use the invisible horizontal and vertical axes passing through the geometric center as measurement references.
– – Check every element individually.
– – When an element extends beyond the authorized area, reduce it uniformly while preserving its proportions, then check it again.
– – The strict 160-pixel border rule always takes precedence over any other safe-area calculation.
– – Never claim that exact geometry has been respected without checking it.
–
—
–
– [20] USE OF APPROVED MODELS AND REFERENCES
–
– – Reuse previously approved structures, models, and methods when applicable.
– – An official model specific to a project must be treated as the reference for that project.
– – Do not merge incompatible models without analysis.
– – Do not modify a locked section of a model.
– – Any evolution of a locked block must be created separately as a variant, appendix, module, or new version.
– – Preserve two distinct reference levels: the validated permanent methodology and the complementary guide.
– – The validated permanent methodology remains the active working method and must not be replaced, removed, or weakened by the complementary guide.
– – The complementary guide must be preserved in addition to the methodology and used when its content is relevant.
– – The complementary guide supplements the methodology; it does not replace it.
– – Always use the latest approved version of the complementary guide.
– – The current active complementary guide is Version 8.
– – When a later complementary-guide version is approved, it becomes the active guide and the earlier versions remain archived for traceability.
– – Never silently merge, replace, or confuse the roles of the methodology and the complementary guide.
–
—
–
– [21] TRANSPARENCY AND FAILURE MANAGEMENT
–
– – Be transparent when research, a check, a conversion, or a creation could not be completed correctly.
– – Never fabricate a result, source, file, date, hash, or check.
– – Do not declare that a file exists without actually identifying it.
– – Do not declare a test successful without performing it.
– – When a gap exists, explain its actual effect on the project.
– – Prefer an honest partial result to a false certification.
– – Explicitly correct every discovered error.
–
—
–
– [22] CERTIFICATION AND COMPLETION OF WORK
–
– – Define the certification conditions in the plan.
– – Do not use “final,” “complete,” “verified,” or “certified” before all these conditions have been successfully met.
– – Before certification, verify:
– – all deliverables;
– – all important sources;
– – all relevant dates;
– – all classifications;
– – all links;
– – all legal and safety requirements;
– – all formatting rules;
– – all user instructions;
– – all unresolved items.
– – Produce, when justified by the project:
– – final audit;
– – final correction log;
– – final unresolved-items register;
– – instruction-compliance matrix;
– – final MANIFEST;
– – SHA-256 checksums;
– – verified final ZIP.
–
—
–
– [23] GENERAL ADAPTATION RULE
–
– – Apply this methodology rigorously, but adapt its level of detail to the size and risk of the work.
– – A small sentence correction does not require the same audit package as a catalog containing several hundred pages.
– – However, the essential principles remain mandatory:
– – plan;
– – verify;
– – research relevant dates;
– – preserve sources and files;
– – respect versions;
– – document significant changes;
– – check results;
– – preserve the resumption point;
– – never certify prematurely.
–
—
–
– STATUS OF PROJECT-SPECIFIC RULES
–
– – The specific rules for Essential Commodore Links, Emu-France, Raspberry Pi, SteamOS/Bazzite, game sheets, Instagram images, and other projects remain memorized separately.
– – They are added to this general methodology when work concerns their project.
– – They must not be removed by this methodology.
–
—
–
– END OF THE PERMANENT GENERAL METHODOLOGY — OFFICIAL VERSION 8
–
———————————
———————————
———————————
———————————
–
—
–
– 2] MY PERMANENT WORKING METHODOLOGY REGARDING DATES
–
—
–
– OFFICIAL PERMANENT RULE REGARDING DATES
–
– PERMANENT CHRONOLOGICAL PROTOCOL AND SYSTEMATIC DATE RESEARCH
–
– FINAL VERSION 2
–
—
–
– [01] OBJECTIVE AND SCOPE
–
– – Systematically research all relevant and identifiable dates for every item present in documents, publications, lists, catalogs, guides, information sheets, tables, audits, research, and other work.
– – Every item must receive an explicit chronological status, even when the result is:
– – exact date found;
– – partial date found;
– – multiple dates found;
– – conflicting date;
– – planned date;
– – estimated date;
– – unconfirmed date;
– – date not found after research;
– – date not applicable.
– – “Date not found” and “date not applicable” are two different results.
– – The depth of the research must be adapted to the importance, risk, and nature of the item.
– – No relevant date must be omitted when it helps identify, distinguish, classify, sort, verify, or audit an item.
–
—
–
– [02] IDENTITY BEFORE CHRONOLOGY
–
– – Determine the canonical identity of the item before assigning it a date.
– – Verify:
– – the official name;
– – former names;
– – aliases;
– – the manufacturer;
– – the author;
– – the developer;
– – the publisher;
– – the owner;
– – the platform;
– – the model;
– – the generation;
– – the version number.
– – Explicitly distinguish:
– – the parent project;
– – the fork;
– – the port;
– – the derivative;
– – the re-release;
– – the remaster;
– – the remake;
– – the hardware revision;
– – the new generation;
– – the commercial edition;
– – the community version;
– – the name change.
– – Never transfer the date of one item to another item bearing a similar name.
– – When an identity remains uncertain, retain “unresolved identity.”
– – Never artificially borrow the chronology of another item.
–
—
–
– [03] MILESTONES TO RESEARCH
–
– – Research, according to the nature of the item:
– – the design or beginning of the project;
– – the creation;
– – the first public mention;
– – the first publication;
– – the announcement;
– – the presentation;
– – the demonstration;
– – the prototype;
– – the crowdfunding campaign;
– – the opening of registrations;
– – the opening of preorders;
– – the launch;
– – the first availability;
– – the first sale;
– – the first shipment;
– – the official release;
– – the stable release;
– – the alpha release;
– – the beta release;
– – the release-candidate publication;
– – the major version;
– – the relevant minor version;
– – the revision;
– – the significant update;
– – the port;
– – the fork;
– – the re-release;
– – the remaster;
– – the name change;
– – the change of owner;
– – the change of publisher;
– – the interruption;
– – the dormancy;
– – the abandonment;
– – the cancellation;
– – the resumption;
– – the replacement;
– – the succession;
– – the end of support;
– – the withdrawal;
– – the end of sales;
– – the end of production;
– – the disappearance of the website;
– – the archiving;
– – any other useful milestone.
– – Do not force all these milestones onto every item.
– – Research only the milestones that are meaningful for the nature of the item.
–
—
–
– [04] SOURCE HIERARCHY
–
– – Give priority to official or primary sources:
– – official website;
– – author;
– – developer;
– – manufacturer;
– – publisher;
– – official repository;
– – Git history;
– – version log;
– – release notes;
– – press release;
– – official documentation;
– – official sales page;
– – official download page;
– – official campaign;
– – original announcement;
– – original video;
– – original publication.
– – Use a reliable secondary source only when the primary source is absent, inaccessible, or insufficient.
– – Clearly indicate the secondary nature of the evidence.
– – Never use the following alone as sufficient evidence:
– – a search-engine excerpt;
– – a cache date;
– – a comment;
– – a forum;
– – an unsourced wiki;
– – a memory;
– – an old summary.
– – One of these sources may help discover a lead, but it is not sufficient on its own to turn a date into an exact date.
–
—
–
– [05] RECORDING EVIDENCE
–
– – For every important date, retain, when relevant:
– – the identity of the item;
– – the type of milestone;
– – the date;
– – the level of precision;
– – the source;
– – the author or organization responsible for the source;
– – the direct URL;
– – the title of the page or publication;
– – the source’s own date;
– – the consultation date;
– – the verification date;
– – a short note explaining what the source actually proves.
– – Verify that the source proves the stated milestone.
– – A source that confirms only the general existence of an item does not necessarily prove its release date.
–
—
–
– [06] PRECISION TAXONOMY
–
– – EXACT DATE:
– – the day, month, and year are explicitly proven;
– – recommended format: YYYY MM DD.
–
– – PARTIAL DATE TO THE MONTH:
– – the year and month are proven;
– – the day is unknown;
– – format: YYYY MM;
– – the “partial date” label is mandatory.
–
– – PARTIAL DATE TO THE YEAR:
– – the year is proven;
– – the month and day are unknown;
– – format: YYYY;
– – the “partial date” label is mandatory.
–
– – PLANNED DATE:
– – the date is announced as future, planned, targeted, or scheduled;
– – it must never be presented as an actual release without subsequent confirmation.
–
– – REPORTED DATE:
– – the date is attributed to a person, organization, or source;
– – the attribution must be retained.
–
– – ESTIMATED DATE:
– – the date is an estimate constructed from evidence;
– – it must never be presented as a verified fact.
–
– – CONFLICTING DATE:
– – several credible sources provide different dates;
– – the different dates must be retained and explained.
–
– – UNCONFIRMED DATE:
– – a date is circulating, but the evidence is insufficient.
–
– – DATE NOT FOUND:
– – genuine research has been performed;
– – no reliable date has been found.
–
– – DATE NOT APPLICABLE:
– – the item has no useful chronological milestone;
– – this may concern a static rule or a generic instruction.
–
– – Never turn a partial, planned, reported, estimated, or unconfirmed date into an exact date.
–
—
–
– [07] MANDATORY CHRONOLOGICAL DISTINCTIONS
–
– – Never confuse:
– – the source date with the event date;
– – the date of a video with the date of the subject presented;
– – the publication date of a page with the project creation date;
– – the date of a re-release with the date of the original work;
– – the date of a fork with the date of the parent project;
– – the date of a port with the date of the original version;
– – the date of a remaster or remake with the date of the original;
– – the date of a current version with the date of the first release;
– – the announcement with actual availability;
– – the preorder with the first sale;
– – the first sale with the first shipment;
– – the prototype with the commercial product;
– – the regional release with the worldwide release;
– – the physical release with the digital release;
– – the beta version with the stable version;
– – the start of development with the first publication.
– – When several milestones are valid, retain them separately.
– – Never arbitrarily choose a single “release date” when several distinct events exist.
–
—
–
– [08] EARLIEST KNOWN DATE AND ACTUAL DATE
–
– – An earliest date found is not automatically the actual creation or launch date.
– – Use precise wording:
– – earliest public mention found;
– – earliest verified availability;
– – earliest documented sale;
– – earliest confirmed shipment;
– – actual date not established.
– – The absence of an earlier source does not prove that no earlier event occurred.
–
—
–
– [09] RELATIVE DATES
–
– – Convert the following expressions into absolute dates when necessary:
– – today;
– – yesterday;
– – tomorrow;
– – last week;
– – next month;
– – soon;
– – any other relative expression.
– – Preserve the original relative wording when it has historical value.
– – Add the interpreted absolute date.
– – Do not allow a relative expression to become ambiguous in a document intended to be preserved.
–
—
–
– [10] TIME ZONES AND CALENDARS
–
– – Verify the time zone when a publication, release, or event may fall on a different date depending on the country.
– – Do not convert a local time or date without knowing the time zone if the conversion could shift the day.
– – Report every time-zone conversion.
– – Preserve the calendar used by the source when it is not the Gregorian calendar.
– – Provide a clearly identified conversion when necessary.
– – Never silently perform a conversion that could alter the date.
–
—
–
– [11] INTERVALS, PERIODS, AND BOUNDARY DATES
–
– – For every research period, record:
– – the start date;
– – the end date;
– – whether the start date is inclusive or exclusive;
– – whether the end date is inclusive or exclusive;
– – the time zone when relevant.
– – Avoid duplicates when a boundary date belongs to two periods.
– – Assign every boundary item to one canonical record.
– – Use a cross-reference in the other period.
– – Distinguish:
– – the period of activity;
– – the period of availability;
– – the duration of support;
– – the preorder window;
– – the production period;
– – the estimated interval.
– – Never turn an interval into an exact day.
–
—
–
– [12] CONFLICT MANAGEMENT
–
– – When one official source contradicts another official source:
– – retain both pieces of information;
– – precisely identify the milestones concerned;
– – verify whether one concerns the announcement and the other the release;
– – verify whether one concerns the sale and the other the shipment;
– – verify whether they concern different regions;
– – verify whether they concern different versions or generations;
– – search for a third primary source;
– – explain the decision.
– – Do not automatically choose:
– – the earliest date;
– – the latest date;
– – the most frequently repeated date.
– – If the conflict remains unresolved, retain the status “conflicting dates.”
– – A secondary source must never silently overwrite a primary source.
–
—
–
– [13] VERSIONS, TAGS, RELEASES, AND COMMITS
–
– – Record separately the dates:
– – of major versions;
– – of hardware revisions;
– – of important branches;
– – of commercial editions;
– – of ports;
– – of forks.
– – Distinguish:
– – stable version;
– – beta;
– – alpha;
– – release candidate;
– – nightly;
– – experimental branch;
– – commercial edition;
– – hardware revision;
– – port;
– – fork.
– – Never use the date of the latest commit as a version’s release date without evidence.
– – Never use the repository creation date as the project creation date without confirmation.
– – Never confuse:
– – tag date;
– – release-publication date;
– – actual availability date.
–
—
–
– [14] AVAILABILITY AND CURRENT STATUSES
–
– – Store availability is a dated observation.
– – It is not automatically a release date.
– – Use wording such as:
– – available when verified on YYYY MM DD;
– – unavailable when verified on YYYY MM DD;
– – preorder open when verified on YYYY MM DD.
– – Never turn the following statements into permanent historical statuses:
– – in stock;
– – sold out;
– – page accessible;
– – temporarily unavailable.
– – Research separately:
– – the date of first availability;
– – the availability status at the time of the audit;
– – the date when sales ended;
– – the date when production ended.
–
—
–
– [15] NORMALIZATION AND FORMAT
–
– – Use the project’s official format when one exists.
– – By default, use YYYY MM DD for complete dates.
– – Preserve partial dates without inventing missing components.
– – Never write 00 for an unknown day or month.
– – Preserve the date as it appears in the source in the evidence register when this helps the audit.
– – Provide the normalized form separately.
– – Use consistent leading zeros for months and days.
– – For file names, use the format specific to the project.
– – Never retroactively modify an official name without necessity.
–
—
–
– [16] CHRONOLOGICAL DEDUPLICATION
–
– – Use the following combination to detect duplicates:
– – canonical identity;
– – milestone type;
– – date;
– – version or generation.
– – Never delete as duplicates two identical dates that correspond to different milestones.
– – Never merge two videos published on the same day without verifying their identity.
– – Never merge two versions sharing a date without verifying their identity.
– – Assign stable identifiers to important records when the project uses registers.
– – Preserve cross-references between:
– – parent project;
– – fork;
– – port;
– – version;
– – re-release.
–
—
–
– [17] SORTING
–
– – Define an explicit sorting rule for every document or register.
– – Use as needed:
– – chronological sorting;
– – alphabetical, then chronological sorting;
– – sorting by platform, then chronologically;
– – sorting by category, then chronologically;
– – any other approved rule.
– – Document every change to the sorting rule.
– – Do not silently change the order of an already approved document.
–
—
–
– [18] INTEGRATION INTO PLANS AND DELIVERABLES
–
– – Integrate chronological research from the planning stage onward.
– – Depending on the importance of the work, provide for:
– – an inventory of items to date;
– – a date and status register;
– – a source register;
– – a conflict register;
– – a register of dates not found;
– – a chronological patch;
– – a before/after report;
– – an audit;
– – a MANIFEST;
– – SHA-256 checksums;
– – a verified ZIP.
– – The first pass must cover every item.
– – The second pass must address identities, dates, or statuses that remain priorities.
– – Consolidation must merge the passes without losing:
– – uncertainties;
– – conflicts;
– – evidence;
– – milestone distinctions.
– – Integration into an official document must remain separate from research.
–
—
–
– [19] QUALITY CHECKS
–
– – Before validation, verify:
– – that every item has a chronological status;
– – that every exact date has sufficient evidence;
– – that every partial date is labeled;
– – that planned dates are not presented as completed events;
– – that source dates and event dates are separated;
– – that forks, ports, re-releases, and versions are distinguished;
– – that conflicts are documented;
– – that boundary dates do not create duplicates;
– – that the format is consistent;
– – that evidence links correspond to the correct item;
– – that changing dates have a verification date.
– – Never declare a chronological audit complete when some inventory items have not been examined.
–
—
–
– [20] FINAL UPDATE AND FREEZE
–
– – Perform a final update before publication or certification of information likely to change.
– – Define a factual freeze date for major projects.
– – After the freeze:
– – log every correction;
– – explain its cause;
– – rerun the affected audits;
– – recalculate the affected files or checksums.
–
—
–
– [21] REAUDIT TRIGGERS
–
– – Perform a new verification when an item:
– – changes version;
– – changes name;
– – changes owner;
– – moves from prototype to preorder;
– – moves from preorder to sale;
– – begins shipping;
– – is canceled;
– – is abandoned;
– – is discontinued;
– – is replaced;
– – changes domain;
– – changes official repository;
– – receives more precise new primary evidence.
– – Never silently retain an old exact date when better evidence proves that it was incorrect.
–
—
–
– [22] PERMANENT PURPOSES
–
– – Use chronology to:
– – avoid duplicates;
– – avoid errors;
– – distinguish projects;
– – distinguish forks;
– – distinguish ports;
– – distinguish re-releases;
– – distinguish remakes;
– – distinguish remasters;
– – distinguish generations;
– – distinguish revisions;
– – distinguish new versions;
– – improve identities;
– – improve classifications;
– – facilitate sorting;
– – facilitate comparisons;
– – facilitate integrations;
– – facilitate audits;
– – reconstruct the history of an item without mixing its milestones;
– – make documents more consistent;
– – make documents more reliable;
– – make documents better designed;
– – make documents more transparent;
– – make documents more effective.
– – Date research is now part of the permanent general methodology.
– – It must never be considered optional when a relevant date exists.
–
—
–
– MEMORY
–
– – Everything is memorized for all chats.
– – This rule must be applied to all current work.
– – This rule must be applied to all future work.
– – Version 8 of the Permanent General Methodology becomes the active version.
– – Versions 1 through 7 remain archived for traceability.
–
—
–
– FILE CHECKS
–
– – The identifiers and checksums of the current Version 8 document must be stored in the external verification package created after the document has been finalized.
– – Do not embed the current document’s own SHA-256 inside that same document, because changing the embedded value would change the file and therefore its SHA-256.
– – Historical checksums from earlier versions remain in their archived packages and must not be presented as the checks of the active version.
– – For every important release, create an external change report, SHA-256 checksum file, MANIFEST, and verified ZIP archive.
– – Verify the ZIP’s integrity and confirm that every file in the ZIP is byte-for-byte identical to its individually downloadable counterpart.
– – Record the exact source file, parent version, final file name, size, line count, SHA-256, validation status, and publication link in the external package.
– – Activate a new version only after all required checks are successful and, when intended for Pastebin, after the exact copy is accepted with the intended visibility.
–
—
–
– END OF THE OFFICIAL PERMANENT RULE REGARDING DATES — FINAL VERSION 2
–
—
–
———————————
———————————
———————————
———————————
–
—
–
– IN FRENCH:
–
—
–
– INTRODUCTION
–
– Ce document présente les deux méthodologies permanentes que j’utilise pour organiser, vérifier et améliorer mes travaux :
–
– 1] MA MÉTHODOLOGIE DE TRAVAIL PERMANENTE GÉNÉRALE
–
– 2] MA MÉTHODOLOGIE DE TRAVAIL PERMANENTE À PROPOS DES DATES
–
– La première méthodologie définit les règles générales appliquées à mes recherches, documents, publications, fichiers, audits et autres travaux.
–
– La seconde méthodologie explique comment les dates doivent être recherchées, vérifiées, classées et utilisées afin d’éviter les doublons et les erreurs, de distinguer correctement les projets et leurs différentes versions, et d’améliorer la cohérence et la fiabilité des documents.
–
—
–
———————————
———————————
———————————
———————————
–
—
–
– MÉTHODOLOGIE GÉNÉRALE PERMANENTE POUR TOUS LES CHATS ET TOUS LES TRAVAUX
–
– VERSION 8 OFFICIELLE
–
– DATE : 2026 08 04
–
– STATUT : RÈGLES GÉNÉRALES PERMANENTES
–
– Cette Version 8 remplace la Version 7 officielle.
–
– Les Versions 1, 2, 3, 4, 5, 6 et 7 doivent rester archivées pour la traçabilité, mais elles ne doivent plus être utilisées comme versions actives.
–
—
–
– [01] CHAMP D’APPLICATION
–
– – Cette méthodologie s’applique à tous les chats, à tous les travaux actuels et à tous les futurs travaux.
– – Elle s’applique notamment aux recherches, documents, publications, listes, catalogues, guides, fiches, tableaux, audits, traductions, corrections, créations de fichiers, intégrations, archives, images et projets complexes.
– – Les règles particulières d’un projet s’ajoutent à cette méthodologie générale.
– – Une règle propre à un projet ne devient pas automatiquement une règle générale, sauf décision explicite de l’utilisateur.
– – Lorsqu’une instruction récente contredit une ancienne instruction, la plus récente doit être appliquée et la modification doit être signalée lorsque la traçabilité du projet l’exige.
– – Aucune règle permanente ne doit être oubliée lors du changement de chat.
–
—
–
– [02] COMMUNICATION, BLOCS DE TEXTE SIMPLES, FICHIERS TXT DE RÉPONSE ET ARCHIVES ZIP
–
– [02.1] RÈGLE GÉNÉRALE OBLIGATOIRE
–
– – Toutes les réponses textuelles doivent être copiées dans un bloc de texte classique simple délimité par trois accents graves.
– – Cette règle a pour objectifs obligatoires :
– – afficher correctement les tirets ;
– – préserver la structure du texte ;
– – faciliter la sélection ;
– – faciliter la copie ;
– – faciliter la conservation et la réutilisation du contenu.
– – Cette règle s’applique dans tous les chats, à tous les travaux actuels et à tous les futurs travaux.
– – Elle s’applique même lorsque la réponse est courte.
–
– [02.2] FICHIER TXT OBLIGATOIRE POUR CHAQUE RÉPONSE
–
– – Pour chaque réponse, créer obligatoirement un fichier TXT téléchargeable contenant l’intégralité du contenu textuel de la réponse.
– – Cette règle s’applique à toutes les réponses, même courtes.
– – Le fichier TXT doit reproduire fidèlement :
– – les titres ;
– – les sous-titres ;
– – les tirets ;
– – les séparateurs ;
– – les paragraphes ;
– – les listes ;
– – les conclusions ;
– – les points de reprise ;
– – les noms de fichiers ;
– – les SHA-256 ;
– – les avertissements ;
– – tout autre contenu textuel fourni dans la réponse.
– – Le fichier TXT de réponse doit être créé avant l’envoi de la réponse.
– – Le lien de téléchargement du fichier TXT doit être fourni en dehors du bloc de texte afin de rester cliquable.
– – Le fichier TXT de réponse devient la copie téléchargeable officielle de la réponse.
– – Ne jamais omettre le fichier TXT sous prétexte que la réponse est courte, simple ou temporaire.
–
– [02.3] RÉPONSES TROP LONGUES POUR UN BLOC DE TEXTE
–
– – Lorsqu’une réponse est trop longue pour être affichée correctement dans un seul bloc de texte simple, ne pas afficher la réponse complète dans le chat.
– – Dans ce cas, fournir la réponse complète uniquement dans un fichier TXT téléchargeable ou dans plusieurs fichiers TXT téléchargeables lorsque la longueur, la structure ou la taille l’exige.
– – Le message visible dans le chat doit rester minimal.
– – Il peut uniquement indiquer :
– – que la réponse complète se trouve dans le fichier TXT ou les fichiers TXT ;
– – le nom du fichier ou des fichiers ;
– – leur statut ;
– – éventuellement les contrôles effectués ;
– – les liens de téléchargement placés en dehors du bloc.
– – Ne jamais tronquer, résumer ou supprimer une partie de la réponse complète dans le fichier TXT ou les fichiers TXT.
– – Lorsque plusieurs fichiers TXT sont nécessaires, préserver l’ordre complet du contenu entre les fichiers.
– – Identifier clairement chaque partie dans les noms de fichiers et dans le contenu.
– – Ne jamais répartir la réponse complète dans de nombreux blocs de texte simples lorsque la réponse est trop longue.
–
– [02.4] ZIP OBLIGATOIRE POUR LES RÉPONSES TROP LONGUES
–
– – Lorsque la réponse complète est fournie uniquement dans un fichier TXT ou dans plusieurs fichiers TXT parce qu’elle est trop longue pour un bloc de texte simple, créer obligatoirement une archive ZIP téléchargeable.
– – Cette archive ZIP doit contenir le fichier TXT ou tous les fichiers TXT constituant la réponse complète.
– – Fournir simultanément :
– – le lien individuel de chaque fichier TXT ;
– – le lien de l’archive ZIP complète.
– – Le ZIP ne remplace jamais les liens individuels.
– – Les liens individuels ne remplacent jamais le ZIP.
– – Vérifier que le ZIP contient exactement les fichiers TXT annoncés.
– – Vérifier l’intégrité du ZIP avant l’envoi.
– – Vérifier que les fichiers contenus dans le ZIP sont identiques aux fichiers TXT téléchargeables individuellement.
– – Lorsque plusieurs fichiers TXT forment une seule réponse, ajouter si nécessaire un fichier d’ordre de lecture ou un MANIFEST dans le ZIP.
– – Ne jamais déclarer un ZIP vérifié sans avoir effectué le test d’intégrité et la comparaison des fichiers.
–
– [02.5] CONTENUS QUI DOIVENT ÊTRE PLACÉS DANS LE BLOC SIMPLE
–
– – Lorsque la réponse n’est pas trop longue, placer dans un bloc de texte classique simple :
– – les réponses ordinaires ;
– – les introductions ;
– – les publications ;
– – les messages ;
– – les courriels rédigés ;
– – les traductions ;
– – les corrections ;
– – les reformulations ;
– – les brouillons ;
– – les textes prêts à publier ;
– – les descriptions ;
– – les listes ;
– – les tableaux textuels ;
– – les titres et sous-titres ;
– – les séparateurs ;
– – les conclusions ;
– – les résumés ;
– – les plannings ;
– – les rapports ;
– – les audits ;
– – les registres ;
– – les procédures ;
– – les instructions ;
– – les points de reprise ;
– – tout autre contenu textuel destiné à être lu, copié, conservé, publié ou réutilisé.
– – Même lorsque la réponse tient dans un bloc simple, fournir également le fichier TXT individuel obligatoire.
–
– [02.6] INTERDICTION DE REMPLACER LE BLOC SIMPLE
–
– – Ne jamais remplacer le bloc de texte classique simple par :
– – un bloc de rédaction spécial ;
– – une carte de contenu ;
– – un encadré propriétaire ;
– – un format décoratif ;
– – un tableau interactif ;
– – un widget ;
– – une présentation dont le texte ne peut pas être copié facilement.
– – Lorsqu’un outil, une interface ou une instruction de niveau supérieur impose un format spécial, reproduire également tout le contenu textuel essentiel dans le fichier TXT obligatoire.
– – Lorsque cela est techniquement possible et que la réponse n’est pas trop longue, reproduire également le contenu dans un bloc de texte classique simple.
– – Le fichier TXT reste la copie complète et officielle.
–
– [02.7] RÈGLE DES TIRETS
–
– – Préserver les tirets visibles au début des lignes lorsque la structure du travail les exige.
– – Les titres, sous-titres, séparateurs, paragraphes, listes, conclusions et points de reprise doivent conserver leurs tirets dans le bloc et dans le fichier TXT.
– – Ne pas laisser le système de mise en forme transformer ou masquer les tirets.
– – Pour les documents et publications dont la règle impose un tiret à chaque ligne, vérifier que chaque ligne commence effectivement par un tiret.
– – Ne jamais supprimer les tirets pour rendre la présentation plus décorative.
–
– [02.8] LIENS DE TÉLÉCHARGEMENT
–
– – Les liens de téléchargement doivent toujours être placés en dehors du bloc de texte afin qu’ils restent cliquables.
– – Le texte expliquant les fichiers, leur statut, leurs SHA-256 et les contrôles effectués doit rester dans le bloc ou dans le fichier TXT complet.
– – Vérifier que chaque lien de téléchargement correspond au fichier annoncé.
– – Le lien du fichier TXT contenant la réponse complète doit toujours être présent.
– – Pour une réponse trop longue, fournir aussi obligatoirement le lien du ZIP contenant le ou les fichiers TXT.
–
– [02.9] EXCEPTIONS TECHNIQUES
–
– – Les contenus dont la syntaxe technique serait corrompue par l’ajout artificiel de tirets doivent conserver leur syntaxe exacte.
– – Cela concerne notamment :
– – le code source ;
– – le JSON ;
– – le CSV ;
– – le XML ;
– – les scripts ;
– – les commandes ;
– – les fichiers de configuration ;
– – les expressions régulières ;
– – les données structurées.
– – Ces contenus doivent rester copiables dans un bloc de code simple approprié et dans le fichier TXT de réponse.
– – Ne jamais ajouter des tirets à l’intérieur d’un contenu technique lorsque cela rendrait le contenu invalide.
–
– [02.10] LANGUE ET STYLE
–
– – Tutoyer l’utilisateur en français.
– – Répondre en français, sauf lorsqu’un projet, un document ou une demande impose une autre langue.
– – Employer une rédaction claire, précise, complète et cohérente.
– – Éviter les affirmations vagues, les raccourcis trompeurs et le jargon inutile.
– – Ne pas supprimer silencieusement une information fournie par l’utilisateur.
– – Lors d’une correction ou d’une traduction, préserver le sens, les noms, les liens, la structure et les contraintes du texte original.
– – Lorsqu’une traduction littérale est demandée, traduire le plus littéralement possible sans introduire d’informations nouvelles.
–
– [02.11] CONTRÔLE DE CONFORMITÉ AVANT ENVOI
–
– – Avant d’envoyer toute réponse, vérifier :
– – qu’un fichier TXT contenant l’intégralité de la réponse a été créé ;
– – que le fichier TXT est téléchargeable ;
– – que le lien vers le TXT est placé hors du bloc ;
– – que le contenu textuel principal se trouve dans un bloc simple lorsque la longueur le permet ;
– – que les tirets sont visibles ;
– – que la structure est conservée ;
– – que le contenu peut être copié facilement ;
– – qu’aucun bloc spécial n’a remplacé la copie simple ;
– – poser explicitement la question de contrôle : « Le contenu principal visible est-il bien entre trois accents graves ? » ;
– – si la réponse à cette question est non, corriger la réponse avant l’envoi ;
– – vérifier en priorité cette règle pour les introductions, publications, messages, courriels, traductions, corrections, brouillons et textes prêts à publier ;
– – lorsqu’un format spécial est imposé techniquement, fournir aussi une copie complète dans un bloc de texte simple lorsque cela est possible et toujours dans le fichier TXT obligatoire ;
– – que les exceptions techniques conservent leur syntaxe exacte ;
– – que la réponse trop longue est fournie intégralement dans le TXT ou les TXT et non tronquée dans le chat ;
– – que le ZIP obligatoire a été créé lorsque la réponse est trop longue ;
– – que le ZIP contient exactement le ou les TXT annoncés ;
– – que l’intégrité du ZIP a été testée ;
– – que les fichiers du ZIP sont identiques aux fichiers individuels.
– – Une réponse non conforme doit être corrigée avant son envoi.
–
—
–
– [03] PLANIFICATION OBLIGATOIRE
–
– – Établir un planning avant tout travail complexe, important, long, documentaire, technique, créatif, de recherche, d’audit, d’intégration ou comportant plusieurs étapes.
– – Pour une tâche simple et immédiate, le planning peut être très court, mais l’ordre logique du travail doit tout de même être déterminé.
– – Le planning doit définir au minimum :
– – l’objectif ;
– – le périmètre ;
– – le point de départ officiel ;
– – les sources et fichiers autorisés ;
– – les dépendances ;
– – l’ordre des étapes ;
– – les contrôles ;
– – les critères de réussite ;
– – les livrables ;
– – les risques et incertitudes ;
– – le point exact de reprise.
– – Relire et analyser profondément le planning avant son adoption.
– – Rechercher les omissions, contradictions, dépendances manquantes, étapes mal ordonnées et risques de traçabilité.
– – Respecter entièrement le planning adopté.
– – Ne pas sauter une étape, un contrôle, un audit ou un livrable obligatoire.
– – Distinguer clairement :
– – travail prévu ;
– – travail en cours ;
– – travail terminé ;
– – travail validé ;
– – travail remplacé ;
– – travail annulé ;
– – travail restant.
– – Ne jamais présenter une étape comme terminée sans preuves et livrables suffisants.
– – Ne jamais présenter un projet comme final, complet, vérifié ou certifié avant la réussite de toutes les conditions finales du planning.
–
—
–
– [04] MODIFICATION ET VERSIONNAGE DES PLANNINGS
–
– – Modifier un planning uniquement lorsqu’un problème réel, une omission, une contradiction, une nouvelle dépendance, un risque de traçabilité, une amélioration nécessaire ou une nouvelle exigence importante est découvert.
– – Signaler clairement le problème ou l’amélioration à l’utilisateur avant d’adopter une modification importante.
– – Expliquer et justifier la modification.
– – Une modification ne doit jamais affaiblir les contrôles existants.
– – Pour un planning important, créer une nouvelle version numérotée.
– – Produire selon les besoins :
– – un rapport de changement ;
– – un nouveau SHA-256 ;
– – un nouveau MANIFEST ;
– – une archive ZIP testée.
– – Ne jamais écraser l’ancienne version.
– – Archiver l’ancienne version et la marquer comme remplacée.
– – Conserver une chaîne claire entre chaque version.
–
—
–
– [05] REPRISE DU TRAVAIL ENTRE LES CHATS
–
– – À chaque reprise, retrouver le planning officiel et le dernier point exact de reprise.
– – Vérifier les travaux réellement terminés et validés.
– – Ne jamais recommencer inutilement un travail déjà validé.
– – Ne jamais sauter un travail restant.
– – Vérifier le statut des fichiers utilisés avant de continuer.
– – Conserver un point exact de reprise à la fin de chaque session ou grande étape.
– – Lorsque le travail change de chat, utiliser les fichiers officiels et les décisions mémorisées comme continuité de référence.
– – Lorsque le chat semble approcher de sa limite pratique de contexte, ou lorsque continuer dans le même chat crée un risque important de perte de continuité, prévenir l’utilisateur suffisamment tôt.
– – Ne pas attendre une interruption, une erreur, une perte de contexte ou la fin brutale du chat avant de préparer la transition.
– – Ne pas prétendre connaître une limite technique exacte lorsqu’elle n’est pas visible ; utiliser une appréciation prudente fondée sur la longueur, la complexité, l’ancienneté, le nombre de fichiers et le nombre de décisions du chat.
– – Avant de passer à un autre chat, fournir un dossier de continuité complet et organisé contenant, lorsque cela est pertinent :
– – le nom exact du projet ;
– – l’objectif actuel ;
– – le plan officiel ;
– – le dernier master officiel ou la dernière base officielle ;
– – les noms de fichiers et les sommes SHA-256 ;
– – les fichiers à conserver ;
– – les versions approuvées, provisoires, remplacées, annulées, archivées ou interdites ;
– – le travail terminé et validé ;
– – le travail restant ;
– – les décisions permanentes et les règles particulières du projet ;
– – les points non résolus, les risques, les incertitudes et les précautions ;
– – le point exact de reprise ;
– – la prochaine action à effectuer ;
– – les liens et les références utiles ;
– – les instructions exactes à copier dans le nouveau chat.
– – Pour les travaux importants ou complexes, créer un fichier TXT téléchargeable de continuité ou de reprise et, lorsque cela est pertinent, une archive ZIP vérifiée, un MANIFEST et un fichier de sommes de contrôle.
– – Avant de recommander le changement de chat, vérifier que tous les fichiers et tous les liens annoncés existent, sont accessibles et correspondent aux versions indiquées.
– – La transition est terminée uniquement lorsque le nouveau chat peut reprendre le travail sans répéter inutilement le travail validé et sans perdre les décisions, les fichiers, la structure ou la traçabilité.
–
—
–
– [06] MÉTHODOLOGIE DE RECHERCHE ET DE VÉRIFICATION
–
– – Rechercher et vérifier les informations nécessaires au lieu de deviner.
– – Privilégier les sources officielles ou primaires :
– – sites des auteurs, fabricants, développeurs ou éditeurs ;
– – documentation officielle ;
– – dépôts officiels ;
– – notes de version ;
– – communiqués ;
– – pages officielles de vente ou de téléchargement ;
– – publications originales.
– – Utiliser des sources secondaires fiables lorsque les sources primaires sont absentes ou insuffisantes.
– – Signaler clairement les limites d’une source secondaire.
– – Ne pas utiliser un extrait de moteur de recherche, un souvenir, un résumé ancien ou un commentaire isolé comme preuve suffisante.
– – Recouper plusieurs sources lorsque les informations sont importantes, conflictuelles ou ambiguës.
– – Distinguer clairement :
– – faits vérifiés ;
– – déclarations d’une source ;
– – inférences ;
– – hypothèses ;
– – informations non confirmées.
– – Ne jamais inventer une information manquante.
– – Conserver explicitement les incertitudes.
– – Lorsqu’une identité est ambiguë, ne pas la remplacer par un produit, projet ou personne portant un nom similaire.
– – Pour les vidéos, examiner les titres et les descriptions et, lorsque cela aide à découvrir une piste, les commentaires.
– – Un commentaire peut aider à identifier une piste, mais ne doit pas constituer seul la preuve d’une date ou d’un statut important.
–
—
–
– [07] PROTOCOLE CHRONOLOGIQUE PERMANENT ET RECHERCHE SYSTÉMATIQUE DES DATES
–
– [07.1] OBJECTIF ET CHAMP D’APPLICATION
–
– – Rechercher systématiquement toutes les dates pertinentes et identifiables de tous les éléments présents dans les documents, publications, listes, catalogues, guides, fiches, tableaux, audits, recherches et autres travaux.
– – Chaque élément doit recevoir un statut chronologique explicite, même lorsque le résultat est :
– – date exacte trouvée ;
– – date partielle trouvée ;
– – dates multiples trouvées ;
– – date conflictuelle ;
– – date planifiée ;
– – date estimée ;
– – date non confirmée ;
– – date introuvable après recherche ;
– – date non applicable.
– – « Date introuvable » et « date non applicable » sont deux résultats différents et ne doivent jamais être confondus.
– – La profondeur de la recherche doit être adaptée à l’importance, au risque et à la nature de l’élément, mais aucune date pertinente ne doit être omise lorsqu’elle aide à identifier, distinguer, classer, trier, vérifier ou auditer.
–
– [07.2] IDENTITÉ AVANT CHRONOLOGIE
–
– – Déterminer l’identité canonique de l’élément avant de lui attribuer une date.
– – Vérifier les noms officiels, anciens noms, alias, fabricants, auteurs, éditeurs, propriétaires, plateformes, générations, modèles et numéros de version.
– – Distinguer explicitement :
– – projet parent ;
– – fork ;
– – portage ;
– – dérivé ;
– – réédition ;
– – remaster ;
– – remake ;
– – révision matérielle ;
– – nouvelle génération ;
– – édition commerciale ;
– – version communautaire ;
– – changement de nom.
– – Ne jamais transférer la date d’un élément vers un autre élément portant un nom proche.
– – Lorsqu’une identité reste incertaine, conserver « identité non résolue » et ne pas lui attribuer artificiellement la chronologie d’un autre élément.
–
– [07.3] JALONS À RECHERCHER
–
– – Rechercher selon la nature de l’élément :
– – conception ou début du projet ;
– – création ;
– – première mention publique ;
– – première publication ;
– – annonce ;
– – présentation ;
– – démonstration ;
– – prototype ;
– – campagne de financement ;
– – ouverture des inscriptions ;
– – ouverture des précommandes ;
– – lancement ;
– – première disponibilité ;
– – première vente ;
– – première expédition ;
– – sortie officielle ;
– – publication stable ;
– – publication bêta, alpha ou candidate ;
– – version majeure ;
– – version mineure pertinente ;
– – révision ;
– – mise à jour importante ;
– – portage ;
– – fork ;
– – réédition ;
– – remaster ;
– – changement de nom ;
– – changement de propriétaire ou d’éditeur ;
– – interruption ;
– – mise en sommeil ;
– – abandon ;
– – annulation ;
– – reprise ;
– – remplacement ;
– – succession ;
– – fin de support ;
– – retrait ;
– – arrêt de vente ;
– – arrêt de production ;
– – disparition du site ;
– – archivage ;
– – tout autre jalon utile.
– – Ne pas forcer tous ces jalons sur chaque élément : rechercher uniquement ceux qui ont un sens pour sa nature.
–
– [07.4] HIÉRARCHIE DES SOURCES ET PREUVES
–
– – Privilégier les sources officielles ou primaires :
– – site officiel ;
– – auteur, développeur, fabricant ou éditeur ;
– – dépôt officiel ;
– – historique Git ou journal de versions ;
– – notes de version ;
– – communiqué ;
– – documentation officielle ;
– – page officielle de vente ou de téléchargement ;
– – campagne officielle ;
– – annonce originale ;
– – vidéo ou publication originale de l’auteur.
– – Utiliser une source secondaire fiable uniquement lorsque la source primaire est absente, inaccessible ou insuffisante.
– – Signaler clairement la nature secondaire de la preuve.
– – Un extrait de moteur de recherche, une date de cache, un commentaire, un forum, un wiki non sourcé, un souvenir ou un ancien résumé ne suffit pas seul pour transformer une date en date exacte.
– – Pour chaque date importante, conserver lorsque cela est pertinent :
– – identité de l’élément ;
– – type de jalon ;
– – date ;
– – précision ;
– – source ;
– – auteur ou organisme de la source ;
– – URL directe ;
– – titre de la page ou publication ;
– – date propre de la source ;
– – date de consultation ou de vérification ;
– – courte note expliquant ce que la source prouve réellement.
– – Vérifier que la source prouve le jalon indiqué et pas seulement l’existence générale de l’élément.
–
– [07.5] TAXONOMIE DE PRÉCISION
–
– – DATE EXACTE :
– – jour, mois et année explicitement prouvés ;
– – format de projet recommandé : AAAA MM JJ.
– – DATE PARTIELLE AU MOIS :
– – année et mois prouvés, jour inconnu ;
– – format : AAAA MM ;
– – étiquette obligatoire : date partielle.
– – DATE PARTIELLE À L’ANNÉE :
– – année prouvée, mois et jour inconnus ;
– – format : AAAA ;
– – étiquette obligatoire : date partielle.
– – DATE PLANIFIÉE :
– – date annoncée comme future, prévue, ciblée ou programmée ;
– – ne doit jamais être présentée comme sortie réelle sans confirmation ultérieure.
– – DATE RAPPORTÉE :
– – date attribuée à une personne, une organisation ou une source ;
– – l’attribution doit être conservée.
– – DATE ESTIMÉE :
– – estimation explicitement construite à partir d’indices ;
– – ne doit jamais être présentée comme fait vérifié.
– – DATE CONFLICTUELLE :
– – plusieurs sources crédibles donnent des dates différentes ;
– – conserver les dates et expliquer le type de jalon ou la contradiction.
– – DATE NON CONFIRMÉE :
– – une date circule mais la preuve est insuffisante.
– – DATE INTROUVABLE :
– – une recherche réelle a été effectuée, mais aucune date fiable n’a été trouvée.
– – DATE NON APPLICABLE :
– – l’élément n’a pas de jalon chronologique utile, par exemple une règle statique ou une instruction générique.
– – Ne jamais transformer une date partielle, planifiée, estimée, rapportée ou non confirmée en date exacte.
–
– [07.6] DISTINCTIONS CHRONOLOGIQUES OBLIGATOIRES
–
– – Ne jamais confondre :
– – date de la source et date de l’événement ;
– – date de publication d’une vidéo et date du sujet présenté ;
– – date de mise en ligne d’une page et date de création du projet ;
– – date d’une réédition et date de l’œuvre originale ;
– – date d’un fork et date du projet parent ;
– – date d’un portage et date de la version d’origine ;
– – date d’un remaster ou remake et date de l’original ;
– – date d’une version actuelle et date de première sortie ;
– – annonce et disponibilité réelle ;
– – précommande et première vente ;
– – première vente et première expédition ;
– – prototype et produit commercial ;
– – sortie régionale et sortie mondiale ;
– – sortie physique et sortie numérique ;
– – version bêta et version stable ;
– – début de développement et première publication.
– – Lorsque plusieurs jalons sont valides, les conserver séparément au lieu de choisir arbitrairement une seule « date de sortie ».
–
– [07.7] PREMIÈRE DATE CONNUE ET DATE RÉELLE
–
– – Une « première date connue » n’est pas automatiquement la date réelle de création ou de lancement.
– – Employer des formulations précises :
– – première mention publique retrouvée ;
– – première disponibilité vérifiée ;
– – première vente documentée ;
– – première expédition confirmée ;
– – date réelle non établie.
– – Ne jamais présenter l’absence de source antérieure comme preuve qu’aucun événement antérieur n’a existé.
–
– [07.8] DATES RELATIVES, FUSEAUX HORAIRES ET CALENDRIERS
–
– – Convertir les expressions relatives telles que « aujourd’hui », « hier », « demain », « la semaine dernière » ou « prochainement » en dates absolues lorsque cela est nécessaire à la compréhension ou à l’audit.
– – Conserver le texte relatif original lorsque sa formulation possède une valeur historique, mais ajouter la date absolue interprétée.
– – Vérifier le fuseau horaire lorsqu’une publication, une sortie ou un événement peut changer de date selon le pays.
– – Ne pas convertir une heure ou une date locale sans connaître le fuseau lorsque cette conversion pourrait déplacer le jour.
– – Conserver le calendrier utilisé par la source lorsqu’il ne s’agit pas du calendrier grégorien et fournir une conversion clairement indiquée si elle est nécessaire.
– – Signaler toute conversion de fuseau ou de calendrier.
–
– [07.9] INTERVALLES, PÉRIODES ET DATES FRONTIÈRES
–
– – Pour toute période de recherche, enregistrer explicitement :
– – date de début ;
– – date de fin ;
– – caractère inclusif ou exclusif de chaque borne ;
– – fuseau horaire lorsque pertinent.
– – Éviter les doublons lorsqu’une date frontière appartient à deux périodes.
– – Attribuer chaque élément frontière à un enregistrement canonique et utiliser une référence croisée dans l’autre période.
– – Distinguer :
– – période d’activité ;
– – période de disponibilité ;
– – durée de support ;
– – fenêtre de précommande ;
– – période de production ;
– – intervalle estimé.
– – Ne jamais transformer un intervalle en jour exact.
–
– [07.10] GESTION DES CONFLITS
–
– – Lorsqu’une source officielle contredit une autre source officielle :
– – conserver les deux informations ;
– – identifier précisément les jalons concernés ;
– – vérifier si l’une concerne l’annonce, l’autre la sortie, la vente, l’expédition, une région ou une version différente ;
– – rechercher une troisième preuve primaire ;
– – expliquer la décision.
– – Ne pas choisir automatiquement la date la plus ancienne, la plus récente ou la plus souvent répétée.
– – Si le conflit reste non résolu, conserver le statut « dates conflictuelles ».
– – Une date secondaire ne doit pas écraser silencieusement une date primaire.
–
– [07.11] VERSIONS, RÉVISIONS ET CANAUX DE PUBLICATION
–
– – Enregistrer séparément les dates des versions majeures, révisions matérielles et branches importantes.
– – Distinguer :
– – version stable ;
– – bêta ;
– – alpha ;
– – candidate ;
– – nightly ;
– – branche expérimentale ;
– – édition commerciale ;
– – révision matérielle ;
– – portage ;
– – fork.
– – Ne pas utiliser la date du dernier commit comme date de sortie d’une version sans preuve.
– – Ne pas utiliser la date de création d’un dépôt comme date de création du projet sans confirmation.
– – Ne pas confondre date de tag, date de publication de release et date réelle de disponibilité lorsque celles-ci diffèrent.
–
– [07.12] DISPONIBILITÉ ET STATUTS ACTUELS
–
– – Une disponibilité en boutique est une observation datée, pas une date de sortie.
– – Employer une formulation telle que :
– – disponible lors de la vérification du AAAA MM JJ ;
– – indisponible lors de la vérification du AAAA MM JJ ;
– – précommande ouverte lors de la vérification du AAAA MM JJ.
– – Ne pas transformer « en stock », « épuisé » ou « page accessible » en statut historique permanent.
– – Rechercher séparément :
– – date de première disponibilité ;
– – état de disponibilité au moment de l’audit ;
– – date d’arrêt de vente ou de production lorsqu’elle est connue.
–
– [07.13] NORMALISATION ET FORMAT
–
– – Utiliser le format de date officiel du projet lorsqu’il existe.
– – Par défaut, utiliser AAAA MM JJ pour les dates complètes destinées aux documents de l’utilisateur.
– – Conserver les dates partielles sans inventer les composants manquants.
– – Ne jamais écrire 00 comme jour ou mois inconnu.
– – Conserver la date telle qu’elle apparaît dans la source dans le registre de preuve lorsque cela aide l’audit, puis fournir la forme normalisée séparément.
– – Utiliser des zéros initiaux cohérents pour les mois et jours.
– – Pour les noms de fichiers, employer le format défini par le projet et ne pas modifier rétroactivement un nom officiel sans nécessité.
–
– [07.14] DÉDOUBLONNAGE, TRI ET IDENTIFIANTS
–
– – Utiliser la combinaison identité canonique + type de jalon + date + version ou génération pour détecter les doublons chronologiques.
– – Ne pas supprimer comme doublon deux dates identiques correspondant à des jalons différents.
– – Ne pas fusionner deux vidéos publiées le même jour ou deux versions partageant une date sans vérifier leur identité.
– – Attribuer un identifiant stable aux enregistrements importants lorsque le projet utilise des registres.
– – Conserver des références croisées entre projet parent, fork, portage, version et réédition.
– – Définir une règle de tri explicite :
– – chronologique ;
– – alphabétique puis chronologique ;
– – plateforme puis chronologique ;
– – ou autre règle approuvée.
– – Documenter tout changement de règle de tri.
–
– [07.15] INTÉGRATION DANS LE PLANNING ET LES LIVRABLES
–
– – Intégrer la recherche chronologique dès le planning.
– – Prévoir selon l’importance du travail :
– – inventaire des éléments à dater ;
– – registre des dates et statuts ;
– – registre des sources ;
– – registre des conflits ;
– – registre des dates introuvables ;
– – patch chronologique ;
– – rapport avant/après ;
– – audit ;
– – MANIFEST ;
– – sommes SHA-256 ;
– – ZIP testé.
– – Une première passe doit couvrir tous les éléments.
– – Une seconde passe ciblée doit traiter les identités, dates ou statuts encore prioritaires.
– – La consolidation doit fusionner les passes sans perdre les incertitudes ni les preuves.
– – L’intégration dans un document officiel doit rester séparée de la recherche.
–
– [07.16] CONTRÔLES DE QUALITÉ
–
– – Avant validation, vérifier :
– – que chaque élément de l’inventaire possède un statut chronologique ;
– – que chaque date exacte possède une preuve suffisante ;
– – que chaque date partielle est étiquetée ;
– – que les dates planifiées ne sont pas présentées comme réalisées ;
– – que les dates de sources et d’événements sont séparées ;
– – que les forks, ports, rééditions et versions sont distingués ;
– – que les conflits sont documentés ;
– – que les dates frontières ne créent pas de doublons ;
– – que le format est cohérent ;
– – que les liens de preuve correspondent au bon élément ;
– – que les dates évolutives possèdent une date de vérification.
– – Ne jamais déclarer un audit chronologique complet si des éléments de l’inventaire n’ont pas été examinés.
–
– [07.17] ACTUALISATION, GEL ET RÉAUDIT
–
– – Pour les informations susceptibles d’évoluer, effectuer une actualisation finale avant publication ou certification.
– – Définir une date de gel factuel pour les grands projets.
– – Après le gel, journaliser toute correction et relancer les audits concernés.
– – Déclencher une nouvelle vérification lorsqu’un élément :
– – change de version ;
– – change de nom ;
– – change de propriétaire ;
– – passe de prototype à précommande ;
– – passe de précommande à vente ;
– – commence à être expédié ;
– – est annulé, abandonné, arrêté ou remplacé ;
– – change de domaine ou de dépôt officiel ;
– – reçoit une preuve primaire plus précise.
– – Ne jamais laisser une ancienne date exacte survivre silencieusement lorsqu’une source primaire ultérieure démontre qu’elle était incorrecte.
–
– [07.18] FINALITÉS PERMANENTES
–
– – Utiliser la chronologie pour :
– – éviter les doublons ;
– – éviter les erreurs ;
– – distinguer les projets, forks, portages, rééditions, remakes, remasters, générations, révisions et nouvelles versions ;
– – améliorer les identités et les classifications ;
– – faciliter les tris, comparaisons, intégrations et audits ;
– – reconstruire l’histoire d’un élément sans mélanger ses jalons ;
– – rendre les documents plus cohérents, plus fiables, mieux conçus, plus transparents et plus efficaces.
– – La recherche des dates fait partie de la méthode de travail générale et ne doit jamais être traitée comme une option facultative lorsqu’une date pertinente existe.
–
—
–
– [08] IDENTITÉS, CLASSIFICATIONS ET DOUBLONS
–
– – Déterminer l’identité canonique de chaque élément.
– – Conserver les alias, anciens noms et noms alternatifs lorsqu’ils sont utiles.
– – Distinguer les projets parents, forks, ports, dérivés, nouvelles générations, révisions et rééditions.
– – Ne jamais fusionner deux éléments uniquement parce qu’ils ont un nom proche.
– – Vérifier les plateformes, fabricants, auteurs, éditeurs, propriétaires et catégories.
– – Détecter les doublons de noms, de contenus, de liens, de vidéos et de jalons.
– – Documenter les fusions, déplacements, exclusions et corrections.
– – Conserver séparément les générations et versions différentes lorsqu’elles ont une identité propre.
–
—
–
– [09] SÉPARATION DES PHASES DE TRAVAIL
–
– – Séparer autant que nécessaire :
– – collecte ;
– – recherche ;
– – vérification ;
– – validation ;
– – consolidation ;
– – intégration ;
– – audit ;
– – correction ;
– – certification ;
– – publication.
– – Une phase de recherche ne doit pas modifier silencieusement un master officiel.
– – Une intégration doit utiliser uniquement des résultats approuvés.
– – Les résultats provisoires ne doivent pas être présentés comme définitifs.
– – Les fichiers de recherche, de travail, de publication, de certification et d’archive doivent être clairement distingués.
–
—
–
– [10] GESTION DES FICHIERS ET DES VERSIONS
–
– – Utiliser des noms de fichiers simples, cohérents, sûrs et explicites.
– – Éviter les caractères pouvant être mal interprétés dans les URL ou les systèmes de fichiers.
– – Vérifier l’uniformité des noms entre les fichiers, le README, le MANIFEST et les liens.
– – Ne jamais écraser un fichier approuvé.
– – Créer une nouvelle version pour chaque modification importante.
– – Identifier clairement le fichier parent d’une nouvelle version.
– – Utiliser le SHA-256 pour identifier les fichiers importants et distinguer les doublons réels des fichiers différents.
– – Ne pas se fier uniquement au nom du fichier.
– – Classer les fichiers selon leur statut :
– – officiel ;
– – approuvé ;
– – provisoire ;
– – remplacé ;
– – annulé ;
– – archivé ;
– – comparaison uniquement ;
– – ne pas utiliser.
– – Conserver les fichiers remplacés ou annulés pour la traçabilité, sans les réutiliser comme base officielle.
– – Vérifier les liens de téléchargement avant la livraison.
– – Utiliser UTF-8 et le BOM lorsque le projet ou la plateforme l’exige.
– – Vérifier les fins de ligne et l’encodage lorsqu’ils sont importants.
–
—
–
– [11] FICHIERS TEXTE TÉLÉCHARGEABLES ET ARCHIVES ZIP
–
– – Pour tous les documents, publications, rapports, audits, plannings, registres, traductions longues, listes importantes et autres livrables textuels, créer un fichier TXT téléchargeable individuellement.
– – Lorsqu’un travail produit plusieurs fichiers textuels, fournir un lien de téléchargement individuel pour chaque fichier.
– – Regrouper également tous les fichiers appartenant au même travail, à la même étape ou au même paquet dans une archive ZIP téléchargeable.
– – Fournir à la fois :
– – les liens individuels des fichiers TXT ;
– – le lien de l’archive ZIP complète.
– – Les liens doivent être placés en dehors du bloc de texte simple.
– – Les fichiers TXT doivent préserver les tirets, les séparateurs, la structure et l’ordre du contenu.
– – Pour les documents textuels destinés à la lecture et à la copie, chaque ligne doit commencer par un tiret lorsque cette règle ne détruit pas un format technique obligatoire.
– – Les formats techniques dont la syntaxe serait corrompue par l’ajout de tirets, notamment le code source, le JSON, le CSV, le XML, les fichiers de configuration et les scripts, doivent conserver leur syntaxe exacte.
– – Utiliser par défaut UTF-8 avec BOM pour les fichiers TXT de publication et de documentation, sauf règle différente propre au projet ou contrainte technique explicite.
– – Employer des noms de fichiers simples, cohérents, sûrs, explicites et sans suffixe accidentel tel que « (1) » dans les livrables finaux.
– – Vérifier chaque fichier avant livraison.
– – Vérifier que chaque lien individuel pointe vers le bon fichier.
– – Lorsque plusieurs fichiers sont regroupés, vérifier que le ZIP contient exactement les fichiers annoncés.
– – Vérifier l’intégrité du ZIP avant de le déclarer valide.
– – Vérifier que les fichiers contenus dans le ZIP sont identiques aux fichiers téléchargeables individuellement.
– – Pour les travaux importants, produire également selon les besoins :
– – un MANIFEST ;
– – un fichier de sommes SHA-256 ;
– – un audit de contenu ;
– – un rapport de changement ;
– – un rapport avant/après.
– – Ne jamais remplacer les liens individuels par le seul ZIP lorsque l’utilisateur doit pouvoir télécharger chaque fichier séparément.
– – Ne jamais fournir uniquement les fichiers individuels lorsqu’un travail comporte plusieurs livrables qui doivent être conservés ensemble.
–
—
–
– [12] LIVRABLES, MANIFESTES ET ARCHIVES
–
– – Pour les travaux importants comportant plusieurs fichiers, prévoir selon les besoins :
– – fichier principal ;
– – registre de recherche ;
– – patch contrôlé ;
– – rapport avant/après ;
– – rapport de changement ;
– – audit ;
– – registre des éléments non résolus ;
– – MANIFEST ;
– – fichier de sommes de contrôle ;
– – archive ZIP.
– – Le MANIFEST doit correspondre exactement aux fichiers livrés.
– – Calculer les SHA-256 après la création définitive des fichiers.
– – Vérifier l’intégrité des archives ZIP.
– – Vérifier que les fichiers contenus dans le ZIP sont identiques aux fichiers autonomes correspondants.
– – Ne pas annoncer un ZIP comme vérifié si le test d’intégrité n’a pas été effectué.
– – Séparer lorsque nécessaire :
– – paquet public ;
– – paquet de certification ;
– – archive historique ;
– – fichiers remplacés ou annulés.
–
—
–
– [13] INTÉGRATIONS ET TESTS DE RÉGRESSION
–
– – Toute intégration importante doit partir d’une base officielle identifiée.
– – Vérifier le nom et le SHA-256 de la base avant l’intégration.
– – Préparer un patch contrôlé lorsque cela est pertinent.
– – Produire un rapport avant/après.
– – Vérifier que les sections non concernées n’ont pas été modifiées.
– – Utiliser des comparaisons et, lorsque cela est utile, des SHA-256 de sections.
– – Effectuer des tests de régression après chaque intégration.
– – Arrêter la progression lorsqu’un contrôle obligatoire échoue.
– – Ne jamais intégrer directement depuis un fichier remplacé, annulé ou non vérifié.
– – Conserver une chaîne de filiation entre les versions.
–
—
–
– [14] AUDITS DE QUALITÉ
–
– – Adapter les audits au travail, mais vérifier systématiquement les domaines pertinents :
– – contenu ;
– – exactitude ;
– – dates ;
– – identités ;
– – classifications ;
– – structure ;
– – ordre ;
– – doublons ;
– – liens ;
– – sources ;
– – sécurité ;
– – légalité ;
– – licences ;
– – cybersécurité ;
– – langue ;
– – orthographe ;
– – terminologie ;
– – formatage ;
– – taille ;
– – conformité aux instructions de l’utilisateur.
– – Relire entièrement les documents importants avant la certification.
– – Conserver un registre des éléments non résolus.
– – Documenter chaque correction importante.
– – Réexécuter les contrôles concernés après une correction.
–
—
–
– [15] LIENS, URL ET SOURCES EN LIGNE
–
– – Vérifier les URL avant la livraison ou la publication lorsque cela est pertinent.
– – Vérifier :
– – destination réelle ;
– – disponibilité ;
– – redirections ;
– – domaine actuel ;
– – HTTPS ;
– – doublons ;
– – paramètres de suivi ;
– – page officielle ;
– – adéquation entre la source et l’affirmation.
– – Préférer un lien direct officiel à un résultat de recherche.
– – Ne jamais remplacer un lien mort par une page concernant un autre projet, produit, fork ou génération.
– – Signaler les liens archivés, morts ou non résolus.
– – Ne pas supprimer silencieusement un lien fourni par l’utilisateur.
–
—
–
– [16] LÉGALITÉ, LICENCES, SÉCURITÉ ET CYBERSÉCURITÉ
–
– – Ne pas ajouter de téléchargement direct illégal, non autorisé ou risqué.
– – Éviter notamment les liens directs vers :
– – ROM protégée ;
– – image d’OS protégée ;
– – image de jeu non autorisée ;
– – pack WHDLoad non autorisé ;
– – torrent ;
– – système préconfiguré contenant des fichiers protégés ;
– – bitstream FPGA non autorisé ;
– – logiciel commercial redistribué sans autorisation.
– – Préférer les pages officielles de projet, de licence, de documentation, de préservation ou d’achat.
– – Distinguer la légalité d’un émulateur de celle des ROM et des logiciels utilisés.
– – Ne pas présenter « abandonware » comme une licence légale.
– – Ne pas considérer automatiquement un dépôt public comme open source ou librement réutilisable.
– – Vérifier les licences et les conditions de redistribution lorsqu’elles sont pertinentes.
– – Conserver les avertissements légaux nécessaires de manière claire et mesurée.
– – Utiliser le document officiel réutilisable de cybersécurité de l’utilisateur lorsque cela est pertinent.
– – Ajouter des sections Safety et Legal lorsque le projet, le document ou les instructions de l’utilisateur l’exigent.
– – Ne pas exagérer les risques et ne pas formuler de certitudes juridiques non vérifiées.
–
—
–
– [17] DOCUMENTS ET PUBLICATIONS
–
– – Préserver la structure officielle adoptée pour chaque projet.
– – Ne pas modifier un bloc déclaré verrouillé.
– – Ne pas supprimer une section, un lien, un titre ou une ligne permanente sans autorisation.
– – Vérifier la cohérence entre le titre, la table des matières, les sections et le contenu.
– – Calculer la taille exacte lorsqu’une plateforme possède une limite.
– – Ne pas scinder un document sans nécessité, sans analyse et sans respecter la décision de l’utilisateur.
– – Préparer une copie publique séparée des audits internes lorsque cela est nécessaire.
– – Vérifier après publication que la plateforme n’a pas altéré les caractères, lignes ou URL.
– – Conserver une sauvegarde locale ou une archive finale lorsque le travail est important.
–
—
–
– [18] MÉTHODOLOGIE PASTEBIN
–
– – Pour tout travail destiné à Pastebin, conserver le master officiel intact et créer une copie de publication séparée.
– – Effectuer un audit de compatibilité prudent avant la publication.
– – Respecter le format TXT demandé et préserver les tirets, les séparateurs, l’ordre et la structure de publication.
– – Calculer les octets, les caractères et les lignes lorsque la taille est importante.
– – Auditer séparément l’anglais et le français avant de les réunir.
– – Rechercher non seulement les mots entiers, mais aussi les fragments, les racines, les mots composés, les pluriels, les conjugaisons, les variantes de casse, les ressemblances orthographiques et les sous-chaînes à l’intérieur de mots plus longs.
– – Examiner les termes et les combinaisons susceptibles d’être interprétés comme sexuels, pornographiques, violents, haineux, extrémistes, malveillants, criminels, liés aux drogues, aux armes, aux blessures, aux parties du corps, aux sous-vêtements ou à d’autres sujets sensibles.
– – Une séquence française précise est un déclencheur confirmé du filtre SMART de Pastebin.
– – Ne jamais reproduire cette séquence dans une copie de publication Pastebin, y compris dans une citation explicative ou à l’intérieur d’un mot anglais.
– – La remplacer selon le contexte par une formulation neutre comme « verified », « vérifie » ou « Vérifie ».
– – Ne pas remplacer aveuglément les autres formes de la même famille de mots sans preuve distincte.
– – Un autre terme français déjà identifié a également été signalé comme problématique et ne doit pas être réintroduit dans une copie de publication acceptée.
– – Une expression française courante désignant le système d’opération peut contenir une sous-chaîne anglaise mal interprétée ; utiliser « OS » dans la copie de publication séparée lorsque cela est nécessaire, tout en conservant le master officiel.
– – Tenir des listes séparées des formes confirmées, probables, soupçonnées et acceptées.
– – Une publication réussie en mode Private ou Unlisted ne prouve pas que la même copie sera acceptée en mode Public.
– – Seule une publication réelle réussie avec la visibilité prévue certifie cette copie exacte.
– – Diagnostiquer une langue à la fois, commencer par une copie minimale, ajouter progressivement les blocs et utiliser une isolation binaire lorsque l’avertissement persiste.
– – Éviter les tentatives identiques trop rapprochées lorsqu’un mécanisme antispam peut influencer le résultat.
– – Examiner les facteurs de risque globaux comme les URL nombreuses ou répétées, les publications presque identiques, l’autopromotion excessive, les longues listes de comptes, les contenus commerciaux sans rapport, les adresses électroniques regroupées, les informations personnelles, les mots de passe ou codes répétés, les paramètres de suivi et les liens raccourcis.
– – Retirer de la copie de publication, lorsque cela est approprié, les paramètres de suivi inutiles, les publicités sans rapport, les coordonnées personnelles regroupées et les liens répétés.
– – Après une publication réussie, conserver le fichier exact accepté, son SHA-256, ses octets, ses caractères, ses lignes, sa visibilité, sa date de publication, son lien public et le journal exact des modifications.
– – Ne jamais déclarer un document compatible avec Pastebin avant que la copie exacte destinée à la publication ait été acceptée avec la visibilité prévue.
–
—
–
– [19] CRÉATION ET MODIFICATION D’IMAGES
–
– – Pour les futures images régies par la méthode permanente de l’utilisateur, utiliser un canevas exactement de 1254 × 1254 pixels.
– – Utiliser un fond noir pur.
– – Produire une image très lumineuse, très claire et extrêmement nette.
– – La netteté extrême doit concerner toute l’image, notamment :
– – textes ;
– – liens ;
– – logos ;
– – illustrations ;
– – petits détails.
– – Conserver une bordure gauche exactement de 160 pixels.
– – Conserver une bordure droite exactement de 160 pixels.
– – Ne pas créer de bordure supérieure ou inférieure imposée par cette règle.
– – Les zones x = 0 à 160 et x = 1094 à 1254 doivent rester totalement vides.
– – Aucun texte, lien, logo, illustration, lumière, lueur, effet ou objet significatif ne doit entrer, toucher ou dépasser ces zones.
– – La zone centrale utilisable est x = 160 à 1094.
– – L’axe vertical central se situe à x = 627.
– – Pour une correction d’image, modifier l’image fournie au lieu de créer une nouvelle conception lorsque l’utilisateur demande une correction.
– – Préserver le message, les couleurs, la typographie, la hiérarchie visuelle et la disposition, sauf instruction contraire.
– – Utiliser les axes invisibles horizontal et vertical passant par le centre géométrique comme références de mesure.
– – Contrôler chaque élément individuellement.
– – Lorsqu’un élément dépasse la zone autorisée, le réduire uniformément en conservant ses proportions, puis le contrôler de nouveau.
– – La règle stricte des bordures de 160 pixels prévaut toujours sur tout autre calcul de zone sûre.
– – Ne jamais prétendre qu’une géométrie exacte a été respectée sans contrôle.
–
—
–
– [20] UTILISATION DES MODÈLES ET RÉFÉRENCES APPROUVÉS
–
– – Réutiliser les structures, modèles et méthodes précédemment approuvés lorsqu’ils sont applicables.
– – Un modèle officiel propre à un projet doit être considéré comme référence pour ce projet.
– – Ne pas fusionner des modèles incompatibles sans analyse.
– – Ne pas modifier une section verrouillée d’un modèle.
– – Toute évolution d’un bloc verrouillé doit être créée séparément sous forme de variante, annexe, module ou nouvelle version.
– – Conserver deux niveaux de référence distincts : la méthodologie permanente validée et le guide complémentaire.
– – La méthodologie permanente validée reste la méthode de travail active et ne doit pas être remplacée, supprimée ou affaiblie par le guide complémentaire.
– – Le guide complémentaire doit être conservé en plus de la méthodologie et utilisé lorsque son contenu est pertinent.
– – Le guide complémentaire complète la méthodologie ; il ne la remplace pas.
– – Toujours utiliser la dernière version approuvée du guide complémentaire.
– – Le guide complémentaire actif actuel est la Version 8.
– – Lorsqu’une version ultérieure du guide complémentaire est approuvée, elle devient le guide actif et les anciennes versions restent archivées pour la traçabilité.
– – Ne jamais fusionner, remplacer ou confondre silencieusement les rôles de la méthodologie et du guide complémentaire.
–
—
–
– [21] TRANSPARENCE ET GESTION DES ÉCHECS
–
– – Être transparent lorsqu’une recherche, un contrôle, une conversion ou une création n’a pas pu être achevé correctement.
– – Ne jamais fabriquer un résultat, une source, un fichier, une date, un hash ou un contrôle.
– – Ne pas déclarer un fichier présent sans l’avoir réellement identifié.
– – Ne pas déclarer un test réussi sans l’avoir exécuté.
– – Lorsqu’une lacune existe, expliquer son effet réel sur le projet.
– – Préférer un résultat partiel honnête à une fausse certification.
– – Corriger explicitement toute erreur découverte.
–
—
–
– [22] CERTIFICATION ET FIN DU TRAVAIL
–
– – Définir les conditions de certification dans le planning.
– – Ne pas employer « final », « complet », « vérifié » ou « certifié » avant la réussite de toutes ces conditions.
– – Avant certification, vérifier :
– – tous les livrables ;
– – toutes les sources importantes ;
– – toutes les dates pertinentes ;
– – toutes les classifications ;
– – tous les liens ;
– – toutes les exigences légales et de sécurité ;
– – toutes les règles de format ;
– – toutes les instructions de l’utilisateur ;
– – tous les éléments non résolus.
– – Produire lorsque le projet le justifie :
– – audit final ;
– – journal final des corrections ;
– – registre final des éléments non résolus ;
– – matrice de conformité aux instructions ;
– – MANIFEST final ;
– – sommes SHA-256 ;
– – ZIP final testé.
–
—
–
– [23] RÈGLE GÉNÉRALE D’ADAPTATION
–
– – Appliquer cette méthodologie avec rigueur, mais adapter son niveau de détail à la taille et au risque du travail.
– – Une petite correction de phrase ne nécessite pas le même paquet d’audit qu’un catalogue de plusieurs centaines de pages.
– – Les principes essentiels restent cependant obligatoires :
– – planifier ;
– – vérifier ;
– – rechercher les dates pertinentes ;
– – préserver les sources et les fichiers ;
– – respecter les versions ;
– – documenter les changements importants ;
– – contrôler les résultats ;
– – conserver le point de reprise ;
– – ne jamais certifier prématurément.
–
—
–
– STATUT DES RÈGLES SPÉCIFIQUES AUX PROJETS
–
– – Les règles particulières d’Essential Commodore Links, Emu-France, Raspberry Pi, SteamOS/Bazzite, des fiches de jeux, des images Instagram et des autres projets restent mémorisées séparément.
– – Elles s’ajoutent à cette méthodologie générale lorsqu’un travail concerne leur projet.
– – Elles ne doivent pas être supprimées par la présente méthodologie.
–
—
–
– FIN DE LA MÉTHODOLOGIE GÉNÉRALE PERMANENTE — VERSION 8 OFFICIELLE
–
———————————
———————————
———————————
———————————
–
—
–
– 2] MA MÉTHODOLOGIE DE TRAVAIL PERMANENTE À PROPOS DES DATES
–
—
–
– RÈGLE PERMANENTE OFFICIELLE SUR LES DATES
–
– PROTOCOLE CHRONOLOGIQUE PERMANENT ET RECHERCHE SYSTÉMATIQUE DES DATES
–
– VERSION 2 FINALE
–
—
–
– [01] OBJECTIF ET CHAMP D’APPLICATION
–
– – Rechercher systématiquement toutes les dates pertinentes et identifiables de tous les éléments présents dans les documents, publications, listes, catalogues, guides, fiches, tableaux, audits, recherches et autres travaux.
– – Chaque élément doit recevoir un statut chronologique explicite, même lorsque le résultat est :
– – date exacte trouvée ;
– – date partielle trouvée ;
– – dates multiples trouvées ;
– – date conflictuelle ;
– – date planifiée ;
– – date estimée ;
– – date non confirmée ;
– – date introuvable après recherche ;
– – date non applicable.
– – « Date introuvable » et « date non applicable » sont deux résultats différents.
– – La profondeur de la recherche doit être adaptée à l’importance, au risque et à la nature de l’élément.
– – Aucune date pertinente ne doit être omise lorsqu’elle aide à identifier, distinguer, classer, trier, vérifier ou auditer un élément.
–
—
–
– [02] IDENTITÉ AVANT CHRONOLOGIE
–
– – Déterminer l’identité canonique de l’élément avant de lui attribuer une date.
– – Vérifier :
– – le nom officiel ;
– – les anciens noms ;
– – les alias ;
– – le fabricant ;
– – l’auteur ;
– – le développeur ;
– – l’éditeur ;
– – le propriétaire ;
– – la plateforme ;
– – le modèle ;
– – la génération ;
– – le numéro de version.
– – Distinguer explicitement :
– – le projet parent ;
– – le fork ;
– – le portage ;
– – le dérivé ;
– – la réédition ;
– – le remaster ;
– – le remake ;
– – la révision matérielle ;
– – la nouvelle génération ;
– – l’édition commerciale ;
– – la version communautaire ;
– – le changement de nom.
– – Ne jamais transférer la date d’un élément vers un autre élément portant un nom proche.
– – Lorsqu’une identité reste incertaine, conserver « identité non résolue ».
– – Ne jamais emprunter artificiellement la chronologie d’un autre élément.
–
—
–
– [03] JALONS À RECHERCHER
–
– – Rechercher selon la nature de l’élément :
– – la conception ou le début du projet ;
– – la création ;
– – la première mention publique ;
– – la première publication ;
– – l’annonce ;
– – la présentation ;
– – la démonstration ;
– – le prototype ;
– – la campagne de financement ;
– – l’ouverture des inscriptions ;
– – l’ouverture des précommandes ;
– – le lancement ;
– – la première disponibilité ;
– – la première vente ;
– – la première expédition ;
– – la sortie officielle ;
– – la publication stable ;
– – la publication alpha ;
– – la publication bêta ;
– – la publication candidate ;
– – la version majeure ;
– – la version mineure pertinente ;
– – la révision ;
– – la mise à jour importante ;
– – le portage ;
– – le fork ;
– – la réédition ;
– – le remaster ;
– – le changement de nom ;
– – le changement de propriétaire ;
– – le changement d’éditeur ;
– – l’interruption ;
– – la mise en sommeil ;
– – l’abandon ;
– – l’annulation ;
– – la reprise ;
– – le remplacement ;
– – la succession ;
– – la fin du support ;
– – le retrait ;
– – l’arrêt de vente ;
– – l’arrêt de production ;
– – la disparition du site ;
– – l’archivage ;
– – tout autre jalon utile.
– – Ne pas forcer tous ces jalons sur chaque élément.
– – Rechercher uniquement les jalons qui possèdent un sens pour la nature de l’élément.
–
—
–
– [04] HIÉRARCHIE DES SOURCES
–
– – Privilégier les sources officielles ou primaires :
– – site officiel ;
– – auteur ;
– – développeur ;
– – fabricant ;
– – éditeur ;
– – dépôt officiel ;
– – historique Git ;
– – journal de versions ;
– – notes de version ;
– – communiqué ;
– – documentation officielle ;
– – page officielle de vente ;
– – page officielle de téléchargement ;
– – campagne officielle ;
– – annonce originale ;
– – vidéo originale ;
– – publication originale.
– – Utiliser une source secondaire fiable uniquement lorsque la source primaire est absente, inaccessible ou insuffisante.
– – Signaler clairement la nature secondaire de la preuve.
– – Ne jamais utiliser seul comme preuve suffisante :
– – un extrait de moteur de recherche ;
– – une date de cache ;
– – un commentaire ;
– – un forum ;
– – un wiki non sourcé ;
– – un souvenir ;
– – un ancien résumé.
– – Une de ces sources peut aider à découvrir une piste, mais elle ne suffit pas seule à transformer une date en date exacte.
–
—
–
– [05] ENREGISTREMENT DES PREUVES
–
– – Pour chaque date importante, conserver lorsque cela est pertinent :
– – l’identité de l’élément ;
– – le type de jalon ;
– – la date ;
– – le niveau de précision ;
– – la source ;
– – l’auteur ou l’organisme de la source ;
– – l’URL directe ;
– – le titre de la page ou de la publication ;
– – la date propre de la source ;
– – la date de consultation ;
– – la date de vérification ;
– – une courte note expliquant ce que la source prouve réellement.
– – Vérifier que la source prouve le jalon indiqué.
– – Une source confirmant uniquement l’existence générale d’un élément ne prouve pas nécessairement sa date de sortie.
–
—
–
– [06] TAXONOMIE DE PRÉCISION
–
– – DATE EXACTE :
– – le jour, le mois et l’année sont explicitement prouvés ;
– – format recommandé : AAAA MM JJ.
–
– – DATE PARTIELLE AU MOIS :
– – l’année et le mois sont prouvés ;
– – le jour est inconnu ;
– – format : AAAA MM ;
– – l’étiquette « date partielle » est obligatoire.
–
– – DATE PARTIELLE À L’ANNÉE :
– – l’année est prouvée ;
– – le mois et le jour sont inconnus ;
– – format : AAAA ;
– – l’étiquette « date partielle » est obligatoire.
–
– – DATE PLANIFIÉE :
– – la date est annoncée comme future, prévue, ciblée ou programmée ;
– – elle ne doit jamais être présentée comme une sortie réelle sans confirmation ultérieure.
–
– – DATE RAPPORTÉE :
– – la date est attribuée à une personne, une organisation ou une source ;
– – l’attribution doit être conservée.
–
– – DATE ESTIMÉE :
– – la date est une estimation construite à partir d’indices ;
– – elle ne doit jamais être présentée comme un fait vérifié.
–
– – DATE CONFLICTUELLE :
– – plusieurs sources crédibles donnent des dates différentes ;
– – les différentes dates doivent être conservées et expliquées.
–
– – DATE NON CONFIRMÉE :
– – une date circule, mais la preuve est insuffisante.
–
– – DATE INTROUVABLE :
– – une véritable recherche a été effectuée ;
– – aucune date fiable n’a été trouvée.
–
– – DATE NON APPLICABLE :
– – l’élément ne possède aucun jalon chronologique utile ;
– – cela peut concerner une règle statique ou une instruction générique.
–
– – Ne jamais transformer une date partielle, planifiée, rapportée, estimée ou non confirmée en date exacte.
–
—
–
– [07] DISTINCTIONS CHRONOLOGIQUES OBLIGATOIRES
–
– – Ne jamais confondre :
– – la date de la source avec celle de l’événement ;
– – la date d’une vidéo avec celle du sujet présenté ;
– – la date de mise en ligne d’une page avec celle de la création du projet ;
– – la date d’une réédition avec celle de l’œuvre originale ;
– – la date d’un fork avec celle du projet parent ;
– – la date d’un portage avec celle de la version d’origine ;
– – la date d’un remaster ou remake avec celle de l’original ;
– – la date d’une version actuelle avec celle de la première sortie ;
– – l’annonce avec la disponibilité réelle ;
– – la précommande avec la première vente ;
– – la première vente avec la première expédition ;
– – le prototype avec le produit commercial ;
– – la sortie régionale avec la sortie mondiale ;
– – la sortie physique avec la sortie numérique ;
– – la version bêta avec la version stable ;
– – le début du développement avec la première publication.
– – Lorsque plusieurs jalons sont valides, les conserver séparément.
– – Ne jamais choisir arbitrairement une unique « date de sortie » lorsque plusieurs événements distincts existent.
–
—
–
– [08] PREMIÈRE DATE CONNUE ET DATE RÉELLE
–
– – Une première date retrouvée n’est pas automatiquement la date réelle de création ou de lancement.
– – Employer des formulations précises :
– – première mention publique retrouvée ;
– – première disponibilité vérifiée ;
– – première vente documentée ;
– – première expédition confirmée ;
– – date réelle non établie.
– – L’absence de source antérieure ne prouve pas qu’aucun événement antérieur n’a existé.
–
—
–
– [09] DATES RELATIVES
–
– – Convertir lorsque nécessaire les expressions suivantes en dates absolues :
– – aujourd’hui ;
– – hier ;
– – demain ;
– – la semaine dernière ;
– – le mois prochain ;
– – prochainement ;
– – toute autre expression relative.
– – Conserver le texte relatif original lorsque sa formulation possède une valeur historique.
– – Ajouter la date absolue interprétée.
– – Ne pas laisser une expression relative devenir ambiguë dans un document destiné à être conservé.
–
—
–
– [10] FUSEAUX HORAIRES ET CALENDRIERS
–
– – Vérifier le fuseau horaire lorsqu’une publication, une sortie ou un événement peut changer de date selon le pays.
– – Ne pas convertir une heure ou une date locale sans connaître le fuseau si cette conversion peut déplacer le jour.
– – Signaler toute conversion de fuseau horaire.
– – Conserver le calendrier utilisé par la source lorsqu’il ne s’agit pas du calendrier grégorien.
– – Fournir une conversion clairement indiquée lorsqu’elle est nécessaire.
– – Ne jamais effectuer silencieusement une conversion susceptible de modifier la date.
–
—
–
– [11] INTERVALLES, PÉRIODES ET DATES FRONTIÈRES
–
– – Pour toute période de recherche, enregistrer :
– – la date de début ;
– – la date de fin ;
– – le caractère inclusif ou exclusif de la date de début ;
– – le caractère inclusif ou exclusif de la date de fin ;
– – le fuseau horaire lorsque cela est pertinent.
– – Éviter les doublons lorsqu’une date frontière appartient à deux périodes.
– – Attribuer chaque élément frontière à un enregistrement canonique.
– – Utiliser une référence croisée dans l’autre période.
– – Distinguer :
– – la période d’activité ;
– – la période de disponibilité ;
– – la durée du support ;
– – la fenêtre de précommande ;
– – la période de production ;
– – l’intervalle estimé.
– – Ne jamais transformer un intervalle en jour exact.
–
—
–
– [12] GESTION DES CONFLITS
–
– – Lorsqu’une source officielle contredit une autre source officielle :
– – conserver les deux informations ;
– – identifier précisément les jalons concernés ;
– – vérifier si l’une concerne l’annonce et l’autre la sortie ;
– – vérifier si l’une concerne la vente et l’autre l’expédition ;
– – vérifier si elles concernent des régions différentes ;
– – vérifier si elles concernent des versions ou générations différentes ;
– – rechercher une troisième preuve primaire ;
– – expliquer la décision.
– – Ne pas choisir automatiquement :
– – la date la plus ancienne ;
– – la date la plus récente ;
– – la date la plus souvent répétée.
– – Si le conflit reste non résolu, conserver le statut « dates conflictuelles ».
– – Une source secondaire ne doit jamais écraser silencieusement une source primaire.
–
—
–
– [13] VERSIONS, TAGS, RELEASES ET COMMITS
–
– – Enregistrer séparément les dates :
– – des versions majeures ;
– – des révisions matérielles ;
– – des branches importantes ;
– – des éditions commerciales ;
– – des ports ;
– – des forks.
– – Distinguer :
– – version stable ;
– – bêta ;
– – alpha ;
– – candidate ;
– – nightly ;
– – branche expérimentale ;
– – édition commerciale ;
– – révision matérielle ;
– – portage ;
– – fork.
– – Ne jamais utiliser la date du dernier commit comme date de sortie d’une version sans preuve.
– – Ne jamais utiliser la date de création d’un dépôt comme date de création du projet sans confirmation.
– – Ne jamais confondre :
– – date du tag ;
– – date de publication de la release ;
– – date réelle de disponibilité.
–
—
–
– [14] DISPONIBILITÉ ET STATUTS ACTUELS
–
– – Une disponibilité en boutique est une observation datée.
– – Ce n’est pas automatiquement une date de sortie.
– – Employer des formulations telles que :
– – disponible lors de la vérification du AAAA MM JJ ;
– – indisponible lors de la vérification du AAAA MM JJ ;
– – précommande ouverte lors de la vérification du AAAA MM JJ.
– – Ne jamais transformer les mentions suivantes en statuts historiques permanents :
– – en stock ;
– – épuisé ;
– – page accessible ;
– – temporairement indisponible.
– – Rechercher séparément :
– – la date de première disponibilité ;
– – l’état de disponibilité au moment de l’audit ;
– – la date d’arrêt de vente ;
– – la date d’arrêt de production.
–
—
–
– [15] NORMALISATION ET FORMAT
–
– – Utiliser le format officiel du projet lorsqu’il existe.
– – Par défaut, utiliser AAAA MM JJ pour les dates complètes.
– – Conserver les dates partielles sans inventer les composants manquants.
– – Ne jamais écrire 00 comme jour ou mois inconnu.
– – Conserver la date telle qu’elle apparaît dans la source dans le registre de preuve lorsque cela aide l’audit.
– – Fournir séparément la forme normalisée.
– – Utiliser des zéros initiaux cohérents pour les mois et les jours.
– – Pour les noms de fichiers, utiliser le format propre au projet.
– – Ne jamais modifier rétroactivement un nom officiel sans nécessité.
–
—
–
– [16] DÉDOUBLONNAGE CHRONOLOGIQUE
–
– – Utiliser la combinaison suivante pour détecter les doublons :
– – identité canonique ;
– – type de jalon ;
– – date ;
– – version ou génération.
– – Ne jamais supprimer comme doublon deux dates identiques correspondant à des jalons différents.
– – Ne jamais fusionner deux vidéos publiées le même jour sans vérifier leur identité.
– – Ne jamais fusionner deux versions partageant une date sans vérifier leur identité.
– – Attribuer des identifiants stables aux enregistrements importants lorsque le projet utilise des registres.
– – Conserver les références croisées entre :
– – projet parent ;
– – fork ;
– – portage ;
– – version ;
– – réédition.
–
—
–
– [17] TRI
–
– – Définir une règle de tri explicite pour chaque document ou registre.
– – Utiliser selon les besoins :
– – tri chronologique ;
– – tri alphabétique puis chronologique ;
– – tri par plateforme puis chronologique ;
– – tri par catégorie puis chronologique ;
– – toute autre règle approuvée.
– – Documenter tout changement de règle de tri.
– – Ne pas modifier silencieusement l’ordre d’un document déjà approuvé.
–
—
–
– [18] INTÉGRATION DANS LES PLANNINGS ET LIVRABLES
–
– – Intégrer la recherche chronologique dès le planning.
– – Prévoir selon l’importance du travail :
– – un inventaire des éléments à dater ;
– – un registre des dates et des statuts ;
– – un registre des sources ;
– – un registre des conflits ;
– – un registre des dates introuvables ;
– – un patch chronologique ;
– – un rapport avant/après ;
– – un audit ;
– – un MANIFEST ;
– – des sommes SHA-256 ;
– – un ZIP testé.
– – La première passe doit couvrir tous les éléments.
– – La deuxième passe doit traiter les identités, les dates ou les statuts encore prioritaires.
– – La consolidation doit fusionner les passes sans perdre :
– – les incertitudes ;
– – les conflits ;
– – les preuves ;
– – les distinctions de jalons.
– – L’intégration dans un document officiel doit rester séparée de la recherche.
–
—
–
– [19] CONTRÔLES DE QUALITÉ
–
– – Avant validation, vérifier :
– – que chaque élément possède un statut chronologique ;
– – que chaque date exacte possède une preuve suffisante ;
– – que chaque date partielle est étiquetée ;
– – que les dates planifiées ne sont pas présentées comme réalisées ;
– – que les dates des sources et des événements sont séparées ;
– – que les forks, ports, rééditions et versions sont distingués ;
– – que les conflits sont documentés ;
– – que les dates frontières ne créent pas de doublons ;
– – que le format est cohérent ;
– – que les liens de preuve correspondent au bon élément ;
– – que les dates évolutives possèdent une date de vérification.
– – Ne jamais déclarer un audit chronologique complet lorsque certains éléments de l’inventaire n’ont pas été examinés.
–
—
–
– [20] ACTUALISATION FINALE ET GEL
–
– – Effectuer une actualisation finale avant la publication ou la certification des informations susceptibles d’évoluer.
– – Définir une date de gel factuel pour les grands projets.
– – Après le gel :
– – journaliser chaque correction ;
– – expliquer sa cause ;
– – relancer les audits concernés ;
– – recalculer les fichiers ou sommes de contrôle affectés.
–
—
–
– [21] DÉCLENCHEURS DE RÉAUDIT
–
– – Effectuer une nouvelle vérification lorsqu’un élément :
– – change de version ;
– – change de nom ;
– – change de propriétaire ;
– – passe de prototype à précommande ;
– – passe de précommande à vente ;
– – commence à être expédié ;
– – est annulé ;
– – est abandonné ;
– – est arrêté ;
– – est remplacé ;
– – change de domaine ;
– – change de dépôt officiel ;
– – reçoit une nouvelle preuve primaire plus précise.
– – Ne jamais conserver silencieusement une ancienne date exacte lorsqu’une meilleure source démontre qu’elle était incorrecte.
–
—
–
– [22] FINALITÉS PERMANENTES
–
– – Utiliser la chronologie pour :
– – éviter les doublons ;
– – éviter les erreurs ;
– – distinguer les projets ;
– – distinguer les forks ;
– – distinguer les portages ;
– – distinguer les rééditions ;
– – distinguer les remakes ;
– – distinguer les remasters ;
– – distinguer les générations ;
– – distinguer les révisions ;
– – distinguer les nouvelles versions ;
– – améliorer les identités ;
– – améliorer les classifications ;
– – faciliter les tris ;
– – faciliter les comparaisons ;
– – faciliter les intégrations ;
– – faciliter les audits ;
– – reconstruire l’histoire d’un élément sans mélanger ses jalons ;
– – rendre les documents plus cohérents ;
– – rendre les documents plus fiables ;
– – rendre les documents mieux conçus ;
– – rendre les documents plus transparents ;
– – rendre les documents plus efficaces.
– – La recherche des dates fait désormais partie de la méthodologie générale permanente.
– – Elle ne doit jamais être considérée comme facultative lorsqu’une date pertinente existe.
–
—
–
– MÉMORISATION
–
– – Tout est mémorisé pour tous les chats.
– – Cette règle doit être appliquée à tous les travaux actuels.
– – Cette règle doit être appliquée à tous les futurs travaux.
– – La Méthodologie générale permanente Version 8 devient la version active.
– – Les Versions 1 à 7 restent archivées pour la traçabilité.
–
—
–
– CONTRÔLES DES FICHIERS
–
– – Les identifiants et les sommes de contrôle du document Version 8 actuel doivent être conservés dans le paquet externe de vérification créé après la finalisation du document.
– – Ne pas intégrer le propre SHA-256 du document actuel à l’intérieur de ce même document, car la modification de la valeur intégrée modifierait le fichier et donc son SHA-256.
– – Les anciennes sommes de contrôle restent dans les paquets archivés de leurs versions et ne doivent pas être présentées comme les contrôles de la version active.
– – Pour chaque version importante, créer un rapport externe de modification, un fichier de sommes SHA-256, un MANIFEST et une archive ZIP vérifiée.
– – Vérifier l’intégrité du ZIP et confirmer que chaque fichier du ZIP est identique octet par octet à son équivalent téléchargeable individuellement.
– – Enregistrer dans le paquet externe le fichier source exact, la version parente, le nom final du fichier, sa taille, son nombre de lignes, son SHA-256, son statut de validation et son lien de publication.
– – Activer une nouvelle version uniquement après la réussite de tous les contrôles requis et, lorsqu’elle est destinée à Pastebin, après l’acceptation de la copie exacte avec la visibilité prévue.
–
—
–
– FIN DE LA RÈGLE PERMANENTE OFFICIELLE SUR LES DATES — VERSION 2 FINALE
–
—
–
———————————
———————————
———————————
———————————
‼️‼️ THANK YOU VERY MUCH.
———————————
———————————
———————————
———————————

AI, IA, Artificial Intelligence, Intelligence Artificielle, ChatGPT